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Voorwoord 


De belangrijkste kenmerken die deze elfde editie onderscheiden van eerdere edities 

zijn: 

* Het in een vroeg stadium presenteren van SQL-query's. 

* Het gebruik van een concentrische benadering bij het ontwerpen van databases. 

+ Het gebruik van de kraaienpootnotatie voor E-R-diagrammen. 

« Het gedetailleerd bespreken van specifieke normaalvormen en van pragmatische 
normalisatietechnieken. 

* Het gebruik van Microsoft Access 2007 en van Microsoft SQL Server 2008. 

* Het maken van online databaseapplicaties met behulp van veelgebruikte 
ontwikkeltechnieken. 

« Het geven van een introductie in business intelligence (BI)-systemen. 

* Het bespreken van de concepten die gebruikt worden bij data warehouses en On- 
Line Analytical Processing (OLAP). 


Veel van deze wijzigingen zijn geïntroduceerd in de tiende editie. De basisstructuur 
van de eerste negen edities was ontworpen voor een leeromgeving die ondertussen 
niet meer bestaat. Studenten hebben tegenwoordig, anders dan tijdens de beginja- 
ren van de databaseverwerking, gemakkelijk toegang tot gegevensmodellering- en 
DBMS-producten. De studenten van tegenwoordig zijn bovendien te ongeduldig om 
een les te beginnen met lange besprekingen van de concepten van het modelleren 
van gegevens en het ontwerpen van databases. Ze willen iets doen, ze willen resulta- 
ten zien en feedback krijgen. Bovendien willen studenten vaardigheden leren waar 
vraag naar bestaat. 


SQL 


Vanwege deze veranderingen in de leeromgeving, biedt dit boek in een vroeg stadi- 
um (hoofdstuk 2) de bespreking van het SQL statement SELECT. De bespreking van 
SQL DDL- en andere DML-statements gebeurt in hoofdstuk 7 en 8. 

Het presenteren van SQL SELECT-statements in hoofdstuk 2 betekent dat stu- 
denten al vroeg leren gegevens op te vragen en resultaten te krijgen en dat ze een 
aantal manieren leren kennen waarop de databasetechniek voor hen van nut zal zijn. 

Dit boek neemt aan dat studenten de SQL-statements en de voorbeelden met een 


SQL-product zullen uitvoeren. Dat is tegenwoordig ook praktisch, want elke student 
heeft toegang tot Microsoft Access. 
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Opmerking 

De presentatie en bespreking van SQL is over drie hoofdstukken verdeeld, zodat studenten dit belangrijke 
onderwerp met kleine brokjes tegelijk kunnen leren. SQL SELECT-statements worden in hoofdstuk 2 
behandeld. SQL DDL- en DML-statements worden in hoofdstuk 7 gepresenteerd. Gecorreleerde subquery’s 
en EXISTS/NOT EXISTS-statements worden in hoofdstuk 8 beschreven. Elk onderwerp wordt behandeld in 
de context van het uitvoeren van nuttige praktijktaken. Gecorreleerde subquery’s worden bijvoorbeeld 


gebruikt voor het verifiëren van aannames voor functionele afhankelijkheden — een taak die nodig is voor 
het herontwerpen van databases. 


Het kader waarin deze tekst staat illustreert een ander kenmerk van deze editie: commentaar wordt in dit 
boek met behulp van dergelijke kaders van de besprekingen gescheiden. Ze presenteren soms aanvullend 
materiaal en worden soms gebruikt om belangrijke concepten te benadrukken. 


Een stapsgewijze benadering voor het ontwerpen van 
databases 


Databases ontstaan tegenwoordig op drie manieren: (1) door het integreren van be- 
staande gegevens uit spreadsheets, gegevensbestanden en uittreksels uit databases, 
(2) door projecten voor het ontwikkelen van nieuwe informatiesystemen en (3) door 
de noodzaak voor het herontwerpen van een bestaande database om deze aan ver- 
anderende eisen aan te passen. Ik realiseerde me, toen ik over deze drie manie- 
ren nadacht, dat deze docenten een veelbelovende didactische mogelijkheid bieden. 
Waarom zouden we het ontwerpen van databases niet drie keer behandelen, één- 
maal voor elke manier, in plaats van het ontwerpen van databases alleen op basis van 


gegevensmodellen te behandelen? Dat idee bleek zelfs nog succesvoller dan ik had 
verwacht. 


Ontwerpen, eerste ronde: databases op basis van bestaande gegevens 
Ik heb mezelf over het ontwerpen van databases op basis van bestaande gegevens 
afgevraagd hoe ik te werk zou gaan als iemand me een reeks tabellen zou geven en 
zou zeggen: ‘Maak daar een database van.’ Ik zou de tabellen in het licht van de cri- 
teria voor het normaliseren bekijken en dan bepalen of de nieuwe databases alleen 
voor het opvragen van gegevens bedoeld zijn, of voor het opvragen en bijwerken van 
gegevens. Ik zou de gegevens samenvoegen door ze te denormaliseren, afhankelijk 
van het antwoord op deze vraag, of ik zou ze uit elkaar halen door ze te normaliseren. 
Dat zijn allemaal dingen die studenten moeten weten en begrijpen. 

De eerste ronde voor het ontwerpen van databases geeft docenten dus een goede 
gelegenheid het normaliseren te behandelen en dat niet als een verzameling theo- 
retische ideeën te doen, maar in plaats daarvan als een nuttig hulpmiddel voor het 
maken van ontwerpbeslissingen voor databases die gemaakt worden op basis van 
bestaande gegevens. Het maken van databases op basis van bestaande gegevens is 
bovendien, zoals ik tijdens recente ervaringen in advieswerk over datamining heb 
opgemerkt, een steeds vaker voorkomende taak, die vaak aan de beginners onder het 
personeel wordt toegekend. Het leren van hoe het normaliseren op het ontwerpen 
van databases op basis van bestaande gegevens wordt toegepast biedt niet alleen een 
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interessante manier voor het behandelen van het normaliseren, maar deze kennis is 
ook nuttig en wordt veel gevraagd! 

Grote organisaties werken verder steeds vaker met gestandaardiseerde software 
van leveranciers zoals SAP, Oracle en Siebel. Maar nu elke organisatie dezelfde soft- 
ware gebruikt, merken veel mensen dat ze alleen een concurrentievoordeel kunnen 
behalen als ze beter gebruik kunnen maken van de gegevens in deze vooraf ont- 
worpen databases. Dat betekent dat studenten die weten hoe ze gegevens moeten 
extraheren en hoe ze alleen-lezen databases moeten maken voor rapportage en data- 
miningvaardigheden hebben opgedaan die nuttig en waardevol zijn in de wereld van 
ERP en andere kant-en-klare softwareoplossingen. 


Ontwerpen, tweede ronde: gegevens modelleren en databases 
ontwerpen 

De tweede manier waarop databases ontstaan is door het ontwikkelen van nieuwe 
systemen. Hoewel dat niet meer zo vaak voorkomt als in het verleden, worden er 
toch nog steeds veel geheel nieuwe databases gemaakt. Studenten moeten dan ook 
nog steeds leren hoe ze gegevens modelleren en ze moeten ook nog steeds leren hoe 
ze gegevensmodellen omzetten in databaseontwerpen. 


Het kraaienpootmodel als standaard 

De negende editie van dit boek maakte uitgebreid gebruik van IDEFrX, maar in ben 
sindsdien tot de conclusie gekomen dat IDEFrX meer problemen veroorzaakt dan 
deze waard is. De kern van het E-R-modelleren kan gemakkelijker worden behan- 
deld door de kraaienpootversie van het E-R-model te gebruiken en ik heb deze versie 
dan ook overal gebruikt. IDEF1X wordt echter in bijlage B uitgelegd, voor het geval 
er behoefte mocht zijn aan het gebruik daarvan. Om dezelfde reden is UML in bij- 
lage C opgenomen. 


Opmerking 

De keuze van een data-modelleringstool is enigszins problematisch. De twee direct beschikbare tools, 
Microsoft Visio en MySQL Workbench van Sun zijn database-ontwerptools, geen modelleringstools. 
Geen van beide kan een N:M-relatie weergeven, maar deze moet worden weergegeven met een 
intersectietabel. Dit verwart het modelleren met ontwerpen, iets wat we studenten juist proberen te 
leren niet te doen. 


Databases ontwerpen op basis van E-R-gegevensmodellen 
Het ontwerpen van een database op basis van gegevensmodellen bestaat, zoals in 
hoofdstuk 6 wordt besproken, uit drie taken: het representeren van entiteiten en 
attributen door tabellen en kolommen, het representeren van maximumkardinali- 
teiten door externe sleutels te maken en te plaatsen en het representeren van mini- 
mumkardinaliteiten door voorwaarden, triggers en toepassingslogica. 

De eerste twee taken zijn niet moeilijk. Ontwerpen voor minimumkardinalitei- 
ten zijn echter ingewikkelder. Vereiste parents kunnen gemakkelijk afgedwongen 
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worden via NOT NULL externe sleutels en referential integrity constraints. Vereiste 
children zijn problematischer. Ik heb de bespreking van dit onderwerp echter ver- 
eenvoudigd ten opzichte van de negende editie door het gebruik van referential inte- 
grity-acties te beperken en door deze acties aan te vullen met ontwerpdocumentatie. 
Hoewel het ontwerpen voor vereiste children ingewikkeld is, is het belangrijk dat 
studenten dat kunnen. Het levert bovendien ook een reden waarom studenten trig- 
gers moeten leren kennen. De bespreking van deze onderwerpen is hoe dan ook veel 
eenvoudiger dan deze in vorige edities was doordat het kraaienpootmodel wordt ge- 
bruikt en omdat er aanvullende ontwerpdocumentatie wordt gebruikt. 


Ontwerpen, derde ronde: databases herontwerpen 

Het herontwerpen van databases is moeilijk, maar komt vaak voor. Informatiesyste- 
men leiden, zoals in hoofdstuk 8 wordt opgemerkt, tot organisatorische wijzigingen. 
Nieuwe informatiesystemen leiden ertoe dat gebruikers zich op nieuwe manieren 
gedragen en gebruikers die zich op nieuwe manieren gedragen vereisen wijzigingen 
in hun informatiesystemen. 

Het herontwerpen van databases — de derde ronde van het ontwerpen van data- 
bases — is ingewikkeld. Je zult dit misschien willen overslaan, afhankelijk van je stu- 
denten. Je kunt dat doen zonder het verband te verliezen. 

Het herontwerpen van databases wordt besproken na de bespreking van SQL 
DDL en DML in hoofdstuk 7, omdat daar het gebruik van geavanceerde SQL voor 
nodig is. Het herontwerpen van databases biedt ook een praktische reden voor het 
behandelen van gecorreleerde subquery’s en EXISTS/NOT EXISTS-statements. 


Bedrijfsinformatie: rapportage en datamining 


Een belangrijk kenmerk van dit boek is een uitgebreid hoofdstuk over bedrijfsin- 
formatiesystemen (ook wel bekend als Business Intelligence- of Bl-systemen). Dit 
hoofdstuk omvat een bespreking van het gegevensbeheer voor datawarehouses en 
datamarts. Het beschrijft ook rapportage- en dataminingtoepassingen, waaronder 
OLAP. 

Hoofdstuk 13 presenteert twee toepassingen die vooral van belang zouden moe- 
ten zijn voor de studenten. De eerste is RFM-analyse, een rapportagetoepassing die 
vaak wordt gebruikt door postorder- en e-commercebedrijven. De hele RFM-analyse 
wordt in hoofdstuk 13 uitgevoerd met alleen standaard SQL-statements. Dit hoofd- 
stuk omvat bovendien ook een market-basketanalyse, die ook alleen wordt uitgevoerd 
met behulp van gecorreleerde SQL-subquery’s. Dit hoofdstuk kan op elk willekeurig 
punt na hoofdstuk 8 worden ingevoegd en kan gebruikt worden om ergens in het 
midden van de cursus het gebruik van SQL in de praktijk te illustreren. 


Actief gebruikmaken van een DBMS-product 


Deze editie neemt zoals al eerder werd vermeld aan dat studenten actief gebruik- 
maken van een DBMS-product. De vraag is echter: welk product? De meesten van 
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ons hebben realistisch gezien vier alternatieven om uit te kiezen: Microsoft Access 
2007, Microsoft SQL Server 2008, Oracle en MySQL. Je kunt elk van deze produc- 
ten gebruiken met dit boek, maar vanwege beperkte ruimte en lestijd hebben we er 
voor gekozen in deze editie van Access 2007 en SQL Server 2008 gebruik te maken. 

Een beknopte handleiding voor het gebruik van Access 2007 vind je in bijlage A. 


Access gebruiken 
Het voornaamste voordeel van Access is de beschikbaarheid. De meeste studenten 
zullen het programma al hebben en mocht dat niet het geval zijn, dan is er gemak- 
kelijk aan te komen. Veel studenten zullen met Access hebben gewerkt in hun inlei- 
ding, of in andere klassen. Bijlage A biedt een inleiding in Access voor studenten die 
er nog niet mee hebben gewerkt, maar die het voor dit boek willen gebruiken. 
Access heeft echter een aantal nadelen. Om te beginnen is Access, zoals in hoofd- 
stuk r wordt uitgelegd, een combinatie van een toepassingengenerator en een DBMS. 
Access verwart studenten, omdat het databaseverwerking en toepassingsontwikke- 
ling door elkaar haalt. Access verbergt de SQL bovendien achter zijn queryverwerker 
en laat deze er daardoor als een minder belangrijke toevoeging uitzien, in plaats van 
als de fundering die deze in werkelijkheid is. Access kan verder, zoals in hoofdstuk 2 
wordt besproken, sommige van de standaard SQL-92 basisstatements niet goed ver- 
werken. Access ondersteunt ten slotte geen triggers. Je kunt triggers simuleren door 
Windows-gebeurtenissen af te vangen, maar dat is een van de standaard afwijkende 
techniek, die de aard van het verwerken van triggers niet goed overdraagt. 


Focus op de verwerking door database-applicaties 


In deze editie maken we duidelijk onderscheid tussen de ontwikkeling van database- 
applicaties en de gegevensverwerking door die applicaties. Dat betekent het volgende: 
* We richten ons op een aantal specifieke databaseapplicaties: 
-__Webgebaseerde database-applicaties 
- Applicaties met gegevensverwerking via XML 
- Business Intelligence (BI)-applicaties. 
* We leggen de nadruk op algemeen beschikbare, onder meerdere besturings- 
systemen draaiende programmeertalen. 
* We beperken het gebruik van speciale bedrijfsgebonden tools en program- 
meertalen. 


Er is in dit boek eenvoudigweg niet genoeg ruimte om zelfs maar een basale 
inleiding te geven in bijvoorbeeld Visual Basic.NET of Java. In plaats daarvan richten 
we ons op relatief makkelijk te leren tools die je meteen kunt toepassen in database- 
applicaties. We gebruiken PHP als taal voor webtoepassingen, en gebruiken Eclipse 
als ontwikkelomgeving (IDE). 
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Een overzicht van de hoofdstukken van de elfde editie 


Hoofdstuk r bereidt de weg voor door databaseverwerking te introduceren, de basis- 
onderdelen van databasesystemen te beschrijven en de geschiedenis van de data- 
baseverwerking samen te vatten. Hoofdstuk 2 presenteert SQL SELECT-statements. 
Dit hoofdstuk omvat ook delen over hoe SQL-statements aan Access, Oracle en SQL 
Server worden doorgegeven. Mochten de studenten voor het eerst met Access wer- 
ken, dan zullen ze ook bijlage A moeten bestuderen. 

De volgende vier hoofdstukken, hoofdstuk 3 tot en met 6, presenteren de eerste 
twee rondes voor het ontwerpen van databases. Hoofdstuk 3 presenteert de princi- 
pes van het normaliseren met de Boyce-Codd-normaalvorm. Het beschrijft de pro- 
blemen van meerwaardige afhankelijkheden en legt uit hoe deze worden opgelost. 
Deze basis in het normaliseren wordt in hoofdstuk 4 toegepast op het ontwerpen van 
databases op basis van bestaande gegevens. 

Hoofdstuk 5 en 6 beschrijven het ontwerpen van nieuwe databases. Hoofdstuk 
5 presenteert het E-R-datamodel. De traditionele E-R-symbolen worden uitgelegd, 
maar het grootste deel van dit hoofdstuk maakt gebruik van de kraaienpootnota- 
tie. Hoofdstuk 5 levert een taxonomie van entiteitentypen, waaronder sterke, 1D-af- 
hankelijke, zwakke maar niet 1D-afhankelijke, subtype en recursieve entiteiten. Het 
hoofdstuk eindigt met een eenvoudig voorbeeld van het modelleren van een data- 

base voor een universiteit. 

Hoofdstuk 6 beschrijft het transformeren van gegevensmodellen in databaseont- 
werpen door entiteiten en attributen in tabellen en kolommen om te zetten, door de 
maximumkardinaliteiten te representeren door externe sleutels te maken en te plaat- 
sen en door de minimumkardinaliteiten te representeren met behulp van DBMS- 
voorwaarden, triggers en toepassingencode. Het voornaamste deel van dit hoofdstuk 
loopt parallel aan de entiteitentaxonomie in hoofdstuk 5. 

Hoofdstuk 7 presenteert SQL DDL en DML. SQL DDL wordt gebruikt voor het 
implementeren van het ontwerp van een in hoofdstuk 6 geïntroduceerd voorbeeld. 
INSERT-, UPDATE- en DELETE-statements worden besproken, net als SQL-views. 
Daarnaast worden ook de principes van het invoegen van SQL in programmacode 
gepresenteerd en triggers en opgeslagen procedures worden uitgelegd. 

Hoofdstuk 8 beschrijft de derde ronde van het ontwerpen van databases, het her- 
ontwerpen van databases. Dit hoofdstuk presenteert SQL voor gecorreleerde subque- 
ny’s en EXISTS/NOT EXISTS-statements en deze statements worden gebruikt in het 
proces voor het herontwerpen. Reverse engineering wordt beschreven en er worden 
basispatronen voor het herontwerpen besproken en toegelicht. 

Hoofdstuk g en ro gaan in op het beheer van bedrijfsdatabases voor meer ge- 
bruikers. Hoofdstuk 9 beschrijft taken voor het databasebeheer, waaronder gelijk 
tijdigheid (concurrency), beveiliging en het maken en terugzetten van back-ups. 
Hoofdstuk ro laat zien hoe je de in hoofdstuk 9 besproken zaken kunt uitvoeren met 

SQL Server 2008. 
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Hoofdstuk rr, 12 en 13 gaan in op standaarden voor het aanspreken van databa- 
ses. Hoofdstuk rr presenteert ODBC, OLE DB, ADO.NET en ASP.NET. Het hoofd- 
stuk geeft een inleiding in PHP (en de Eclipse IDE) en illustreert het gebruik van 
databases via webpagina's. Hoofdstuk 12 beschrijft de integratie van XML en data- 
basetechnieken. Hoofdstuk 13 besluit dit boek met een bespreking van Bl-systemen, 
datawarehouses en datamarts. Het illustreert het gebruik van SQL voor RFM- 
rapportageanalyse en voor market basket-analyse. 


Website 


Op de bijbehorende website www. pearsoneducation.nl/kroenke vind je extra Engels- 
talig studiemateriaal: Solutions manual en Student Data Files. 
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Deel 1 


Aan de slag 


De twee hoofdstukken van deel 1 bieden een inleiding in de databaseverwerking. 
In hoofdstuk 1 gaan we in op de kenmerken van databases en beschrijven we be- 
langrijke databasetoepassingen. Hoofdstuk 1 beschrijft ook de diverse onderdelen 
van databases en geeft een overzicht van de kennis die je uit dit boek moet opdoen. 
Daarnaast vat dit hoofdstuk de geschiedenis van de databaseverwerking samen. 

In hoofdstuk 2 begin je te werken met een database en leer je hoe je Structured 
Query Language (SQL), een taal voor het verwerken van databases, gebruikt voor 
het uitvoeren van databasehandelingen. je leert hoe je gegevens opvraagt uit een 
of meer tabellen en je pakt een praktijkvoorbeeld aan met SQL: je zoekt met SQL 
naar patronen in aandelenbeursgegevens. Deze twee hoofdstukken samen geven je 
een idee van wat databases zijn en hoe ze worden verwerkt. 


reren rm aat ern Add 


Hoofdstuk 1 
Inleiding 


Dit hoofdstuk biedt een inleiding in databaseverwerking. We nemen aan dat je op zijn 
minst enige kennis hebt van het werken met databases. We gaan ervan uit dat je met 
een product als Microsoft Access hebt gewerkt voor het invoeren van gegevens in for- 
mulieren, voor het maken van rapporten en misschien voor het uitvoeren van zoek- 
opdrachten. Als je nog nooit dit soort dingen hebt gedaan, raden we je aan Microsoft 
Access 2007 aan te schaffen en de handleiding in bijlage A van dit boek door te werken: 
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1.1 De kenmerken van databases 


Het doel van een database is mensen helpen gegevens bij te houden. Het meest ge- 
bruikte soort database is een relationele database. We gaan in hoofdstuk 3 dieper in 
op relationele databases, voor dit moment is het genoeg om een paar elementaire 
dingen over databases te weten. 

Om te beginnen bergt een relationele database data op in tabellen. Data zijn ge- 
gevens zoals naam en adres, en getallen. Een tabel heeft rijen en kolommen, net als 
een spreadsheet. Een database bevat in principe meer tabellen. Elke tabel bevat gege- 
vens over iets anders. Je ziet bijvoorbeeld een database met twee tabellen in Figuur 


1-1 De tabel STUDENT bevat gegevens over studenten, de tabel VAK bevat gegevens 
over schoolvakken. 


STUDENT 
Voornaam 
Sam 
Marcia 
Louis 


Studentnummer 


Achternaam E-mailadres 


Kok@OnzeU.edu 
Lerik@OnzeU.edu 


Holman@OnzeU.edu 
Groen@OnzeU.edu 


|_Vaknummer |_ Vaknaam | trimester | sectie | 
__20 _ |schekunder [ea | 2 | 
30 105 1 
40 [Accounting Jes | 1 


sl Accounting 2 T05 1 


Figuur 1-1 De tabellen STUDENT en VAK 


Elke rij van de tabel STUDENT bevat gegevens over één student: Kok, Lerik, Holman 
en Groen. Elke rij van de tabel VAK bevat op een soortgelijke manier gegevens over 
een specifiek vak. Een specifieke student of een bepaald vak heet ook wel een instan- 
tie. De gegevens van een bepaalde instantie die in een rij staan, noemen we ook wel 
een record. Elke kolom van een tabel bevat een bepaald kenmerk dat de instanties 


met elkaar gemeen hebben. Zo bevat de eerste kolom van STUDENT het Student- 
nummer, de tweede kolom de Achternaam, enzovoort. 


1.1.1 lets over naamconventies 


Namen van tabellen schrijven we in dit boek in hoofdletters. Deze conventie maakt 
het je makkelijk namen van tabellen te herkennen. Je bent echter niet verplicht na- 
men van tabellen in hoofdletters te schrijven. Microsoft Access en soortgelijke pro- 
gramma's staan je toe de naam van een tabel te schrijven zoals jij dat wilt, dus als 
STUDENT, student, Student, stuDent, of op elke andere gewenste manier. 
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Namen van kolommen beginnen in dit boek altijd met een hoofdletter. Ook dit is 
niet verplicht en heeft alleen als doel om de kolommen beter herkenbaar te maken. 
We zullen soms samengestelde kolomnamen gebruiken, waarbij we elk element met 
een hoofdletter beginnen om de leesbaarheid te bevorderen. Zoals AantalInBestel- 
ling of KostenKoekjes. Deze schrijfwijze is ook alleen weer een handige conventie. 
Consequent gebruik ervan versimpelt het interpreteren van databasestructuren. Zo 
weet je bijvoorbeeld altijd dat STUDENT de naam is van een tabel, en dat Student de 
naam is van een kolom van een tabel. 


1.1.2 Een database omvat gegevens en relaties 

Figuur r-1 laat zien hoe gegevens in de tabellen van een database zijn opgeslagen, 
maar een database is niet compleet als de relaties tussen de rijen van de verschillen- 
de tabellen niet duidelijk zijn. 

Het belang hiervan is in Figuur 1-2 te zien. De tabel bevat een aantal cijfers maar 
de relaties ontbreken. De gegevens in CIJFER zijn nutteloos als je niet weet welk cij- 
fer bij welke student hoort. Het is alsof je een sportverslaggever alleen de uitslagen 
hoort voorlezen: 1-1, 2-0, 2-3, 5-2. Dergelijke uitslagen zijn nutteloos als je niet weet 
over welke wedstrijden het gaat. Een database bevat daarom niet alleen gegevens 
maar ook de relaties tussen die gegevens. 

[__ CIJFER 
sien 
| 


EZ 
Figuur 1-2 De tabel CIJFER 


In Figuur 1-3 zie je de complete tabel met niet alleen cijfers, maar ook met de relaties 
naar de tabellen uit Figuur r-r. Bijvoorbeeld Studentnummer 400 (Groen) heeft het 
cijfer 7,9 gekregen in Vaknummer 40 — en dat is ‘Accounting 1’. Hij heeft verder het 
cijfer 7,5 in Vaknummer 5o — dat is ‘Accounting 2’. 


CIJFER 
Vaknummer 


Studentnummer 


| 


Figuur 1-3 De tabel CIJFER met relaties 


diddl 


nt 
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Figuur 1-1 en Figuur 1-3 laten nog een ander belangrijk aspect van databases zien: 
elke rij bevat een unieke waarde, de zogeheten primaire sleutel. Deze waarde ge- 
bruiken we om de relatie tussen de tabellen aan te geven. In de tabel STUDENT 
is Studentnummer de primaire sleutel. Elke waarde van Studentnummer is uniek, 
komt dus maar één keer voor, en hoort bij precies één student. Zo hoort Student 


nummer roo bij student Kok. Op dezelfde manier heeft elk vak in de tabel VAK een 
eigen Vaknummer. 


Als je Figuur 1-3 en 1-4 vergelijkt zie je dat aan elke rij van CIJFER de primaire sleu- 
tel van STUDENT en van VAK is toegevoegd (Studentnummer en Vaknummer). De 
combinatie van Studentnummer en Vaknummer maken elke rij in CIJFER uniek, 
we noemen dit een vreemde sleutel (of externe sleutel of foreign key). De sleutel heet 
vreemd omdat hij afkomstig is uit een andere (= vreemde) tabel. De vreemde sleutel 
geeft de relatie tussen de tabellen aan. 


STUDENT CUFER 
9 Studentnummer Cijfer 
Achternaam 
Voornaam 
Emailadres 


Û vaknummer 


9 Studentnummer 


Vaknaam 
Y vaknummer 


Trimester 
Sectie 


Figuur 1-4 STUDENT, CIJFER EN VAK in Access 2007 


Figuur 1-4 laat de manier zien waarop Microsoft Access 2007 tabellen en hun on- 
derlinge relaties toont. Het sleutelsymbool geeft de primaire en vreemde sleutels 
aan. De symbolen bij de verbindingslijnen die de relatie aangeven (het cijfer 1 en het 


symbool voor oneindig ce) geven bijvoorbeeld aan dat één student gekoppeld kan zijn 
aan veel cijfers. 


1.1.3 Databases produceren informatie 

Je weet wellicht wat het verschil is tussen gegevens en informatie. Gegevens zijn op- 
geslagen cijfers of feiten. Informatie is kennis die is afgeleid van gegevens. Anders 
gezegd: informatie is weergave van gegevens in een zinvolle context. 

Databases slaan cijfers en feiten — dus gegevens — op. Dat wordt op een manier 
gedaan die het mogelijk maakt informatie te produceren. De gegevens in Figuur 1-3 
kunnen we gebruiken om het gemiddelde cijfer van een student te produceren, het 
gemiddelde cijfer van een vak, het gemiddelde aantal studenten per vak, enzovoort. 
In hoofdstuk 2 leer je de taal Structured Query Language (SQL) kennen, waarmee je 
op basis van databasegegevens informatie kunt produceren. 

Samenvattend: Databases slaan gegevens op in tabellen en representeren de re- 
laties tussen de rijen van die tabellen. Dat gebeurt op een manier die het mogelijk 
maakt informatie te produceren. 
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1.2 Voorbeelden van databases 


Databases maken tegenwoordig deel uit van vrijwel elk informatiesysteem. Dat is 
ook niet verrassend als we bedenken dat elk informatiesysteem gegevens en relaties 
daartussen moet opslaan. 


1.2.1 Voorbeelden van databasetoepassingen 
In Figuur 1-5 zijn enkele toepassingen van databases genoemd. 


Toepassing < d _Ì Gebruikt door bijvoorbeeld Aantal gebruikers [ Gebruikelijke grootte 
[Beheer van verkoopcontacten | Verkoper Es LA mer: | 2000 tijen 
| Afspraken voor patiënten | Medisch kantoorpersoneel 15 tot 50 100.000 rijen 


(arts, tandarts) 


| Customer Relationship | Verkoop-, marketing- of 1500 b | 10 miljoen rijen 

| Management (CRM) ms | klantenserviceafdelingen En Er 
| Enterprise Resource Processing | Een hele organisatie ne 5000 [Meer dan 10 miljoen 

| (ERP) ven En | ee Î > EIC en 

| site voor e-commerce | Internetgebruikers Kan miljoenen zijn Meer dan 1 miljard 

| Ed Kn ce, DE Fn - SE $ _ rijen 

| Digitaal dashboard {Leidinggevend personeel _ [500 _ __| 100.000 rijen 

| Datamining Zakelijke analyse 25 100.000 tot meerdere 
| miljoenen 


emt n E 


Figuur 1-5 Voorbeelden van het gebruik van databases 


1.2.2 Single-user-databasetoepassingen 
De eerste applicatie in Figuur 1-5 wordt door een enkele verkoopster gebruikt. Ze 
houdt ermee bij welke klanten ze belde en wat voor contact ze met hen had. 


1.2.3 Multi-user-databasetoepassingen 

De volgende toepassingen in Figuur 1-5 zijn allemaal bedoeld voor meer dan één 
gebruiker. De applicatie voor het plannen van afspraken voor patiënten kan bijvoor- 
beeld vijftien tot vijftig gebruikers hebben. Dat zullen secretaresses zijn, kantoor- 
beheerders, dokters, tandartsen, verpleegsters, enzovoort. Een dergelijke database 
zal misschien zo'n roo.ooo rijen gegevens in vijf tot tien verschillende tabellen 
omvatten. 

Wordt een databaseapplicatie door meer dan één werknemer gebruikt, dan be- 
staat altijd de kans dat het werk van de ene gebruiker in conflict komt met dat van 
een andere gebruiker. Twee secretaresses kunnen bijvoorbeeld een afspraak op het- 
zelfde tijstip inplannen voor twee verschillende patiënten. Er zijn speciale mecha- 
nismen voor het coördineren van activiteiten in de database en het voorkomen van 
dergelijke conflicten. Je leert deze mechanismen kennen in hoofdstuk 9. 

De derde rij in Figuur 1-5 toont een nog grotere databaseapplicatie. Customer 
Resource Management (CRM) is een informatiesysteem dat contacten met klan- 
ten beheert van de eerste aanvraag tot de acceptatie, aankoop, volgende aanko- 
pen, ondersteuning, enzovoort. CRM-systemen worden gebruikt door verkopers, 
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bedrijfsleiders, klantenservice en ander personeel. Een CRM-database van een wat 
groter bedrijf zou vijfhonderd gebruikers kunnen hebben en ro miljoen of meer rij- 
en in vijftig of meer tabellen. 

Enterprise Resource Planning (ERP) is een informatiesysteem waar alle afde- 
lingen van een fabricagebedrijf gebruik van maken, bijvoorbeeld verkoop, inventa- 
risbeheer, productplanning, inkoop en andere bedrijfsfuncties. SAP is de grootste 
leverancier van ERP-applicaties en heeft als een van de belangrijkste productonder- 
delen een database die gegevens van deze diverse bedrijfsfuncties integreert. Een 


ERP-systeem kan vijfduizend of meer gebruikers hebben en meer dan roo miljoen 
rijen in honderden tabellen. 


1.2.4 E-commerce-databasetoepassingen 

E-commerce is ook een belangrijke toepassing van databases. Databases worden 
gebruikt voor het invoeren van bestellingen, factureren, verzenden en klanten- 
ondersteuning. De grootste databases bij een e-commercesite zijn verrassend ge- 
noeg niet de databases voor het verwerken van bestellingen, maar die voor het 
bijhouden van het browsergedrag van klanten. De meeste prominente e-commer- 
cebedrijven, zoals Amazon.com (www.amazon.com), houden bij welke webpagina's 
en onderdelen van webpagina's hun klanten bekijken. Ze houden ook bij waarop de 
klanten klikken, wat ze aan hun boodschappenkarretjes toevoegen, wat ze bestel- 
len, welke boodschappenkarretjes ze annuleren, enzovoort. E-commercebedrijven 
gebruiken databases met webactiviteiten om te bepalen welke webpagina-items po- 
pulair en succesvol zijn en welke niet. Ze voeren ook experimenten uit om te bepalen 
of een paarse achtergrond meer bestellingén oplevert dan een blauwe achtergrond, 
enzovoort. Dergelijke databases voor gebruik van het web zijn enorm. 


1.2.5 Rapportage en datamining 


De laatste twee voorbeelden uit Figuur 1-5 zijn digitale dashboards en applicaties 
voor datamining. Deze applicaties gebruiken de bestaande gegevens en vatten deze 
samen om de gegevens inzichtelijker te maken of nieuwe informatie te creëren als 
hulp voor de bedrijfsleiding. Digitale dashboards en andere rapportsystemen maken 
overzichten van de voormalige en huidige bedrijfsprestaties. Applicaties voor data- 


mining voorspellen de toekomstige prestaties. In hoofdstuk 15 kijken we naar der- 
gelijke applicaties. 


Opmerking 

Dat een database klein is, betekent niet dat deze ook een eenvoudige structuur heeft. Neem bijvoorbeeld 
een bedrijf dat per jaar voor € 1 miljoen aan onderdelen verkoopt en een bedrijf dat per jaar voor 

€ 100 miljoen aan onderdelen verkoopt. Deze bedrijven hebben soortgelijke databases, ongeacht het 
verschil in omzet. Ze hebben beide dezelfde soorten gegevens, ongeveer hetzelfde aantal tabellen met 
gegevens en hetzelfde niveau aan ingewikkeldheid in de gegevensrelaties. Het enige verschil tussen 


deze twee zit in de hoeveelheid gegevens. Een database voor een klein bedrijf mag dan misschien wel 
klein zijn, het betekent niet noodzakelijk dat deze ook eenvoudig is. 
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1.3 De onderdelen van een databasesysteem 


Zoals je in Figuur 1-6 ziet, bestaat een databasesysteem gewoonlijk uit vier verschil- 
lende onderdelen: gebruikers, de databaseapplicatie, het databasemanagement- 
systeem (DBMS) en de database zelf. Omdat de Structured Query Language (SQL) 
een belangrijke internationale standaardtaal is die alle commerciële DBMS-produc- 
ten ondersteunen, kunnen we het plaatje van het databasesysteem verfijnen tot dat 
van Figuur 1-7. 


AA Databaseapplicatie ome 
mn 


Gebruikers 


, Maken 
* Verwerken 
* Beheren 


Figuur 1-6 De onderdelen van een databasesysteem 
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Figuur 1-7 De onderdelen van een databasesysteem met SQL 


In Figuur 1-7 zie je aan de rechterkant de database, een verzameling van onder- 
ling gerelateerde tabellen en andere structuren. Het databasemanagementsysteem 
(DBMS) is een groot en ingewikkeld computerprogramma om de database te ma- 
ken, te gebruiken en te beheren. Het DBMS ontvangt opdrachten die gecodeerd zijn 
in SQL en vertaalt deze opdrachten in acties op de database. 


Een databaseapplicatie is een verzameling van een of meer computerprogramma’s 
die als intermediair fungeert tussen de gebruiker en het DBMS. De applicatie leest 
of verandert de gegevens in een database door SQL-opdrachten naar het DBMS te 
sturen. Een applicatie kan gegevens aan de gebruiker tonen in de vorm van invoer- 
formulieren en rapporten. 

De gebruikers zijn het vierde onderdeel van het databasesysteen. Zij gebruiken 
de databaseapplicatie om allerlei gegevens bij te houden. 
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1.3.1 Databaseapplicaties en SQL 

De basisfuncties van databaseapplicaties zijn: 

« maken en verwerken van invoerformulieren; 
« verwerken van query's; 

+ maken en verwerken van rapporten; 

* uitvoeren van de applicatielogica; 

+ beheer voeren over de hele applicatie. 


In het vervolg van dit boek behandelen we bovengenoemde punten uitvoerig, maar 
een paar ervan lichten we hier kort toe. 


STUDENT tum: « Achternaam s Voornaam - Emailadres 
100 xoil Sam 


400 Groen Gerda 


\Recorg MO dvans p He C Zoeken 


Figuur 1-8 Invoerformulier 


In Figuur 1-8 zie je een typisch invoerformulier voor de student-vak-cijferdatabase 
uit de vorige paragrafen. Merk op dat dit formulier de structuur van de onderliggen- 
de tabellen voor de gebruiker verbergt. Het doel van dit formulier is dan ook, net als 
dat van alle invoerformulieren, de gebruikers de gegevens in een vorm te presente- 
ren die voor hen bruikbaar en zinvol is, ongeacht de onderliggende tabelstructuur. 


Een belangrijke functie van de databaseapplicatie is het verwerken van query’s. De 
applicatie stuurt de query in de vorm van een SQL-opdracht aan het DBMS. Hier- 
onder zie je een voorbeeld van een SQL-opdracht voor het verwerken van de gege- 
vens uit de STUDENT-tabel van Figuur 1-r: 
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SELECT Achternaam, Voornaam, E-mailadres 
FROM STUDENT 
WHERE Studentnummer > 200; 


Dit SQL-statement haalt de namen en e-mailadressen op van alle studenten die een 
Studentnummer hebben dat groter is dan 200. Uitgaande van de gegevens in Figuur 
LL levert dit statement de Achternaam, de Voornaam en het E-mailadres van de stu- 
denten Holman en Groen. 


1.3.2 Het DBMS 

Het DBMS, of databasemanagementsysteem, verwerkt SQL-opdrachten en maakt, 
verwerkt en beheert de database. Een DBMS is een groot en ingewikkeld computer- 
programma. Er zijn maar weinig organisaties die hun eigen DBMS-programma'’s 
schrijven. In plaats daarvan schaffen ze licenties aan voor DBMS-producten bij gro- 
te databaseleveranciers. Een van de DBMS-producten is Microsoft Access. Andere 
commerciële DBMS-producten zijn Oracle Database van Oracle, DB2 van IBM, SQL 
Server van Microsoft en MySQL van Sun Microsystems/Oracle. Er bestaan tiental- 
len andere DBMS-producten maar deze vijf hebben het leeuwendeel van de markt. 


1.3.3 De database 

Het laatste onderdeel dat je in Figuur 1-7 ziet, is de database. Een database is een 
zichzelf beschrijvende verzameling van geïntegreerde tabellen. Geïntegreerde tabel- 
len zijn tabellen die zowel gegevens als de relaties tussen deze gegevens bevatten. 
De tabellen in Figuur 1-3 zijn geïntegreerd, want ze slaan niet alleen gegevens op over 
studenten, vakken en cijfers, maar ook gegevens over de relaties tussen de rijen van 
verschillende tabellen. 

Een database is zichzelf beschrijvend, want deze bevat een beschrijving van zich- 
zelf. Dat wil zeggen dat databases niet alleen tabellen bevatten met gegevens van 
gebruikers, maar ook tabellen die deze gegevens beschrijven. Dergelijke gegevens 
noemen we metagegevens, omdat dit gegevens over gegevens zijn. De vorm en de 
indeling van de metagegevens variëren van DBMS tot DBMS. 

Figuur 1-9 toont algemene metagegevenstabellen, die de tabellen en de kolom- 
men beschrijven van de database uit Figuur 1-4. 


r 


Tabelnaam AantalKolommen PrimaireSleutel 
STUDENT 3 Studentnummer 
| VAK 4 Vaknummer 
LCIJFER 3 (Studentnummer, Vaknummer) 
Lengte (bytes) 
25 
100 


Kolomnaam mjn Tabelnaam 
Studentnummer J STUDENT 
Achternaam STUDENT 
Voornaam STUDENT 
E-mailadres 


integer 
Text 


uh 
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Datatype 


Lengte (bytes) 


vaknummer [VAK 


4 
VAK ek 
Trimester Text 12 4) 
integer | 4 


Studentnummer 
Vaknummer 


CIJFER _leese IE a 
CIJFER Integer |L 4 
CIJFER [pecimal_ | 

Figuur 1-9 Een voorbeeld van metagegevenstabellen 


Je kunt de metagegevens bekijken om te bepalen of bepaalde tabellen, kolommen, 
indexen of andere structuren in een database bestaan. Het volgende statement vraagt 
SQL Server bijvoorbeeld in de metagegevenstabel SYSOBJECTS na te kijken of er 
een gebruikerstabel (Type = ‘U’) met de naam VAK bestaat in de database. Is dat het 
geval, dan wordt deze tabel uit de database verwijderd. 


If Exists 
(SELECT % 
FROM SYSOBJECTS 
WHERE [Name] = 'VAK! 


AND Tp en Ue) 
DROP TABLE VAK; 


Maak je niet druk over de syntaxis van dit statement. Je leert verderop in dit boek wat 
dit statement precies betekent en hoe je zelf dergelijke statements schrijft. Je hoeft 


hier alleen te weten dat dit een van de manieren is waarop databasebeheerders ge- 
bruikmaken van metagegevens. 


1.4 Persoonlijke versus bedrijfs-databasesystemen 


We kunnen databasesystemen en DBMS-producten in twee groepen verdelen: per- 
soonlijke databasesystemen en bedrijfssystemen. 


1.4.1 Wat is Microsoft Access? 

Voordat we verdergaan, moeten we een veelvoorkomende misvatting uit de weg rui- 
men: Microsoft Access is niet alleen een DB. Het is een persoonlijk databasesys- 
teem: een DBMS plus een applicatiegenerator. Microsoft Access omvat een DBMS, 
dat de database maakt, verwerkt en beheert. Het omvat ook onderdelen voor formu- 
lieren, rapporten en query’s, die samen de applicatiegenerator van Microsoft Access 
vormen. 

De onderdelen van Microsoft Access zie je in Figuur 1-10. De applicaties van 
Microsoft Access maken intern gebruik van SQL voor het communiceren met het 
DBMS. De DBMS-engine (de ‘motor’) van Access heet Jet. Je zult maar zelden iets 
over Jet horen, want Microsoft verkoopt Jet niet als een afzonderlijk product. 
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se verwerken van 
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verwerken van 
query's 
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en 
7 
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Gebruikers 


Het DBMS kan Jet zijn 
(het eigen DBMS van MS 
Access), of SQL Server 


Figuur 1-10 Onder de motorkap van een MS Access-applicatie 
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en 


Microsoft Access is bedoeld voor individueel gebruik en voor kleine werkgroepen. 
Microsoft heeft er alles aan gedaan om de onderliggende databasetechnologie zo veel 
mogelijk te verbergen voor de gebruiker. Hoewel dit een goede strategie is voor be- 
ginnende gebruikers die met kleine databases te maken hebben, werkt dit niet voor 
databaseprofessionals die te maken hebben met applicaties zoals die staan beschre- 
ven in Figuur 1-5. Bij grotere en meer complexe databases is het noodzakelijk de on- 


derdelen en technologie te begrijpen die Access verbergt. 


1.4.2 Databasesystemen voor bedrijven 


Figuur 1-11 toont de onderdelen van een databasesysteem van een groot bedrijf. De 
applicaties en het DBMS zijn hier niet onder één noemer gebracht, zoals dat bij 
Microsoft Access het geval is. De applicaties zijn in plaats daarvan gescheiden van 


elkaar en van het DBMS. 


SAP-applicaties over 
het bedrijfsnetwerk 


(client-server) 


Applicaties voor 
e-commerce op 
een webserver 


Database 


Gebruikers Webportaal met 
rapportageapplicaties 


* Verwerken 
, Beheren 


Applicaties voor 
XML-webservices 


Figuur 1-11 De structuur van een databasesysteem van een groot bedrijf 
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1.4.3 Databaseapplicaties in een bedrijfsdatabasesysteem 

Zoals je in de lijst in Figuur 1-5 kon zien, bestaan er tientallen verschillende soor- 
ten databaseapplicaties.Figuur 1-11 toont applicaties die via een bedrijfsnetwerk 
verbinding maken met de database. Dergelijke applicaties worden soms ook wel 
client-serverapplicaties genoemd, omdat het applicatieprogramma een client is die 
verbinding maakt met een databaseserver. Client-serverapplicaties worden vaak ge- 
schreven in VB.Net, C++ of Java. 

Een tweede categorie van applicaties die je in Figuur 1-11 ziet, omvat e-commerce 
en andere applicaties die op een webserver worden uitgevoerd. De gebruikers ma- 
ken verbinding met dergelijke applicaties via webbrowsers zoals Internet Explorer, 
Mozilla Firefox of Google Chrome. Veelgebruikte webservers zijn bijvoorbeeld 
Internet Information Server (IIS) van Microsoft en Apache. Talen zoals PHP, Java 
en de Microsoft.NET-talen, zoals C# en VB.NET, worden vaak gebruikt voor web- 
serverapplicaties. We bespreken enkele van de technieken voor dergelijke applicaties 
in hoofdstuk rr. 

Rapportageapplicaties die de resultaten van databasequery’s op een bedrijfsportaal 
of een andere website publiceren, vormen een derde categorie. Veel van dergelij- 
ke rapportageapplicaties worden gemaakt met behulp van producten voor het ma- 
ken van rapporten en digitale dashboardproducten van andere leveranciers, zoals 
Cognos en MicroStrategy. 

XML-webservices vormen de laatste categorie van applicaties. Deze applicaties 
zijn het allernieuwste op het gebied van databaseverwerking. Ze gebruiken een com- 
binatie van de XML en andere standaarden om het programma’s mogelijk te maken 
onderling te communiceren. Webservices kunnen worden geschreven in Java, of in 
welke van de .NET-talen dan ook. We bespreken deze belangrijke nieuwe klasse van 
applicaties in hoofdstuk 13. 

Al deze databaseapplicaties verplaatsen gegevens van en naar de database door 
opdrachten te geven aan de DBMS-SQL. Dergelijke applicaties kunnen hiermee for- 
mulieren en rapporten maken of hun resultaten met andere programma’s delen. 


1.4.4 Het DBMS 


Figuur 1-12 toont de vier belangrijkste DBMS-producten. Deze producten worden 
getoond in volgorde van toenemende kracht, mogelijkheden en complexiteit in ge- 
bruik. Microsoft Access (feitelijk Jet) is het makkelijkst te gebruiken en het minst 
krachtig. MySQL is een krachtig opensource-DBMS dat vaak voor webtoepassingen 
wordt gekozen. 

Microsoft SQL Server is veel krachtiger dan zijn stalgenoot Acces. SQL Server 
kan grotere databases verwerken, is sneller en bevat mogelijkheden voor het regelen 
van simultane toegang voor meerdere gebruikers, voor het maken en terugzetten 
van reservekopieën en voor andere beheersfuncties. 

DBa is een DBMS-product van IBM. Veel mensen zullen het ermee eens zijn 
dat DBa sneller presteert dan SQL Server en grotere databases kan verwerken. Met 
IBM DBa valt echter ook moeilijker te werken. Het snelste DBMS met de meeste 
mogelijkheden is Oracle van Oracle Corporation. Oracle is te configureren voor het 
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Microsoft Microsoft IBM Oracle Corp. 
Access (Jet) SQL Server DB2 Oracle 

Toenemende 

kracht en - _— ee — 

aantal features 

Toenemende 

complexiteit — _— ES mn 

in gebruik 


Figuur 1-12 Algemene indruk van professionals van DBMS-producten 


leveren van uiterst snelle prestaties voor uitermate grote databases die jaar in jaar uit 
24 uur per dag moeten blijven werken. Het werken met en beheren van een Oracle- 
DBMS is veel moeilijker dan bij Microsoft SQL Server. 


1.5 _Databaseontwerp 


Het ontwerpen van databases is zowel moeilijk als belangrijk. Het bepalen van de 
juiste structuur van de tabellen, de juiste relaties tussen de tabellen, geschikte gege- 
vensvoorwaarden en andere structurele onderdelen kan moeilijk en soms zelfs inti- 
miderend zijn. De wereld is dan ook vol van slecht ontworpen databases. Dergelijke 
databases presteren niet goed. Ze vereisen misschien van applicatieprogrammeurs 
dat ze overmatig ingewikkelde en gekunstelde SQL schrijven om de gewenste gege- 
vens op te halen. Het zal misschien moeilijk zijn ze aan nieuwe of veranderde eisen 
aan te passen, of ze schieten op andere manieren tekort. 

Het ontwerpen van databases is zo'n moeilijk en belangrijk onderwerp dat we er 
het grootste deel van de eerste helft van dit boek aan wijden. Zoals Figuur 1-13 laat 
zien zijn er drie soorten databaseontwerpen: 

+ _op basis van bestaande gegevens; 
* nieuwe systemen; 
« herontwerp. 


1.5.1 Databases ontwerpen op basis van bestaande gegevens 

Het eerste soort databaseontwerp betreft databases die worden gemaakt op basis van 
bestaande gegevens. Zoals je in Figuur 1.14 ziet, krijgt een ontwikkelteam soms een 
reeks spreadsheets of tekstbestanden met gegevens. Het team moet dan een data- 
base ontwerpen en de gegevens uit deze spreadsheets en tabellen in de nieuwe da- 
tabase importeren. 

Het is ook mogelijk databases te maken op basis van uittreksels uit andere da- 
tabases. Dit alternatief wordt vooral veel gebruikt voor rapportageapplicaties en 
dataminingapplicaties. Je kunt er bijvoorbeeld gegevens uit een in gebruik zijnde 
database, zoals een CRM- of ERP-database, mee naar een nieuwe database kopi- 
eren, die je alleen gebruikt voor verdere analyses. Dergelijke databases worden, 
zoals hoofdstuk 13 laat zien, gebruikt in voorzieningen die we datawarehouses en 
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[oe soorten databaseontwerpen 
| 


i hoofdstuk 3 en 4). 
| « Op basis van bestaande gegevens ( 
| d Analyseer spreadsheets en andere gegevenstabellen 


Exlraheer gegevens uit andere databases, RE 
Gebruik de principes van het normaliseren voor he 


* Nieuwe systemen ontwikkelen (hoofdstuk 5 en 6). ae 
Maak een datamodel op basis van applicatie-eisen. 
Zet het datamodel om in een databaseontwerp. 


* Databases herontwerpen (hoofdstuk 8). 
Migreer oude naar nieuwe databases. 


Integreer twee of meer databases. 
Gebruik de principes van het normaliseren en het omzetten van datamodellen voor reverse 


engineering en het ontwerpen van nieuwe databases. 


“ Opmerking: Hoofdstuk 7 bespreekt het implementeren van databases met SQL. Je hebt deze kennis 
nodig om het herontwerpen van databases te begrijpen. 


Figuur 1-13 Drie soorten databaseontwerpen 
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datamarts noemen. De gegevens uit dergelijke databases worden vaak geëxporteerd 
naar andere analysehulpmiddelen en “Programma's, zoals Enterprise Miner van 
SAS, Clementine van SPSS of I-Miner van Insightful Corporation. 

Databaseontwikkelaars bepalen de juiste structuur voor de nieuwe database. Een 
veelvoorkomend probleem hierbij is hoe de diverse bestanden of tabellen in de nieu- 
we database aan elkaar gerelateerd moeten zijn. Zelfs het importeren van een enkele 
tabel kan ontwerpproblemen met zich meebrengen. Figuur 1-1 5 toont twee verschil 
lende manieren voor het importeren van een eenvoudige tabel met werknemers en 
hun afdelingen. Moeten deze gegevens worden opgeslagen als een enkele tabel of 
als twee tabellen? 

Dergelijke beslissingen zijn niet arbitrair. Professionele databaseontwerpers ma- 
ken gebruik van voorschriften die bekendstaan als normalisatie of normaalvormen. 
Normalisatieregels dienen als leidraad voor het beoordelen van databaseontwerpen. 
Deze regels en hun rol in het ontwerpen van databases leer je kennen in hoofdstuk B 


ArdNum _ | ArdNaam AfdNum _ | ArdNaam 
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Marels 
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(a) Ontwerp met één tabel 


nn, 


(b) Ontwerp met twee tabellen 


Figuur 1-15 Gegevens importeren: een of twee tabellen? 


1.5.2 Databaseontwerp voor nieuwe systemen 

Een tweede situatie waarin databases worden ontworpen, is voor nieuwe informa- 
tiesystemen. Zoals je in Figuur 1-16 ziet, worden de eisen voor een nieuw systeem 
(zoals gewenste gegevensinvoerformulieren en “Tapporten, door gebruikers gestel. 
de eisen, gebruiksvoorbeelden, Enzovoort) geanalyseerd om het databaseontwerp te 
maken. 


een van de moeilijkste stappen. H 
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nodig om het herontwerpen van databases te begrijpen. 
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datamarts noemen. De gegevens uit dergelijke databases worden vaak geëxporteerd 
naar andere analysehulpmiddelen en “Programma's, zoals Enterprise Miner van 
SAS, Clementine van SPSS of I-Miner van Insightful Corporation. 

Databaseontwikkelaars bepalen de juiste structuur voor de nieuwe database. Een 
veelvoorkomend probleem hierbij is hoe de diverse bestanden of tabellen in de nieu- 
we database aan elkaar gerelateerd moeten zijn. Zelfs het importeren van een enkele 
tabel kan ontwerpproblemen met zich meebrengen. Figuur 1-1 5 toont twee verschil 
lende manieren voor het importeren van een eenvoudige tabel met werknemers en 
hun afdelingen. Moeten deze gegevens worden opgeslagen als een enkele tabel of 
als twee tabellen? 

Dergelijke beslissingen zijn niet arbitrair. Professionele databaseontwerpers ma- 
ken gebruik van voorschriften die bekendstaan als normalisatie of normaalvormen. 
Normalisatieregels dienen als leidraad voor het beoordelen van databaseontwerpen. 
Deze regels en hun rol in het ontwerpen van databases leer je kennen in hoofdstuk B 
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Figuur 1-15 Gegevens importeren: een of twee tabellen? 


1.5.2 Databaseontwerp voor nieuwe systemen 

Een tweede situatie waarin databases worden ontworpen, is voor nieuwe informa- 
tiesystemen. Zoals je in Figuur 1-16 ziet, worden de eisen voor een nieuw systeem 
(zoals gewenste gegevensinvoerformulieren en “Tapporten, door gebruikers gestel. 
de eisen, gebruiksvoorbeelden, Enzovoort) geanalyseerd om het databaseontwerp te 
maken. 
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Figuur 1-16 Ontwerp van databases voor nieuwe systemen 


vergelijken met een bouwplan of een blauwdruk die wordt gebruikt als een leidraad 
voor het ontwerpen van de database. 

Je maakt in hoofdstuk 5 kennis met de meest populaire techniek voor het ma- 
ken van datamodellen: de entiteit-relatiediagrammen (ERD). Je ziet daarna in hoofd- 
stuk 6 hoe je entiteit-relatiediagrammen omzet in databaseontwerpen. 


1.5.3 Databases herontwerpen 


De derde situatie waarin databases worden ontworpen, betreft het herontwerpen van 
bestaande databases. Zoals je in Figuur 1-17 ziet, zijn er twee veelvoorkomende re- 
denen voor het herontwerpen van databases. Een database wordt in het eerste geval 
aan nieuwe of gewijzigde eisen aangepast. Dat proces wordt ook wel het migreren 
van databases genoemd. Er kunnen tijdens het migratieproces tabellen en relaties 
worden gemaakt, gewijzigd of verwijderd. 

De database wordt ook wel eens herontworpen om twee of meer databases met 
elkaar te integreren. Dat komt voor als er oudere systemen worden aangepast of 
verwijderd, of als twee of meer voorheen gescheiden informatiesystemen worden 
samengevoegd. 

Je moet SQL-statements voor het definiëren van databasestructuren en meer ge- 
avanceerde SQL-statements voor query’s en voor het bijwerken van databases ken- 
nen als je het herontwerpen van databases wilt begrijpen. We gaan dan ook pas na 


hoofdstuk 7, waarin we geavanceerde SQL introduceren, op het herontwerpen van 
databases in. 
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Figuur 1-17 Databases die resulteren uit het herontwerpen van databases 


1.6 Watje moet weten 


Met betrekking tot het gebruik van een database zijn er twee rollen te onderkennen: 
de gebruiker en de beheerder. De gebruikers van een database houden zich voorna- 
melijk bezig met het opstellen van SQL-statements voor het ophalen en opslaan van 
de gewenste gegevens. De beheerders van een database houden zich voornamelijk 
bezig met het onderhouden van de database. Je ziet in Figuur 1-18 welke gebieden 
elk van deze rollen omvat. 
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Clientapplicaties 
in C# of 
VB.NET 


Database 


Gebruikers . Jet 
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Figuur 1-18 De werkgebieden van gebruikers en databasebeheerders 
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Zowel gebruikers als beheerders hebben alle kennis nodig die ze in dit boek kunnen 
opdoen. De nadruk op de verschillende onderwerpen kan echter per groep verschil- 
lend zijn. Figuur 1-19 laat het volgens de auteur relatieve belang van de onderwerpen 
voor elke groep zien. 


Onderwerp Hoofdstuk Belang voor kenniswerker Belang voor 
en programmeur databasebeheerder 
1 1 
Ontwerpen via normalisatie 2 | 1 
Gegevensmodellering oJ 1 1 
Datamodellen omzetten 6 2 1 
DDL SAL ï 2 1 
Constraints afdwingen 7 3 1 
names 
Databases herontwerpen B 3 2, maar 1 voor leidinggevende 
databasebeheerders 
Databasebeheer CEN 
Specifieke informatie over SQL Server 10 3 1 
Technieken voor databaseapplicaties 


1 = heel belangrijk, 2 = belangrijk, 3 = minder belangrijk 
Waarschuwing: meningen kunnen verschillen. Vraag je docent(e) wat zijn of haar mening is. 


Figuur 1-19 De prioriteiten voor wat je moet weten 


1.7 _De geschiedenis van de databaseverwerking in het kort 


De databaseverwerking kwam zo rond 1970 op en heeft zich sindsdien voortdurend 
verder ontwikkeld. De voortdurende veranderingen op dit gebied hebben het tot een 
fascinerend en leuk werkgebied gemaakt. Figuur 1-20 vat de belangrijkste tijdperken 
van de databaseverwerking samen. 


Belangrijke 
Re 
voor 1970 | Bestandsbeheer 
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System2000, Total, 
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Figuur 1-20 De geschiedenis van de databaseverwerking 


Opmerkingen 


Vóór databases Alle gegevens werden opgeslagen in 
afzonderlijke bestanden. Het integreren van 
gegevens was heel moeilijk. Opslagruimte voor 
bestanden was duur en de grootte ervan was 
beperkt. 
De eerste producten die gerelateerde tabellen 
leverden. CODASYL DBTG en hiërarchische 
datamodellen (DL/I) overheersten. | 
De eerste DBMS-producten moesten een 
aanzienlijke inertie overwinnen. De voordelen 


bleken het na verloop van tijd te winnen. 


Vroege databases ADABAS, 


Opkomst van het 
relationele model 
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Tijdperk | jaren | Belangrijke Opmerkingen 
| | producten Er 
| DBMS-producten voor | 1982-1992 | dBase-Il, R:base, | Database op pc's. Alle DBMS-producten voor pc's 
| microcomputers Paradox, MS Access | werden aan het begin van de jaren negentig 


| | | weggevaagd door Microsoft Access. 


| Objectgeoriënteerde | 1985-2000 Oracle ODBMS en Nooit populair geworden. Vereiste het 


DBMS'en andere | converteren van relationele databases. Te veel 
je En werk en te weinig zichtbare voordelen. 
| Webdatabases | 1995- IIS, Apache, PHP, ASP. | De toestandloze aard van http was eerst 
| heden NET en Java |een probleem. De eerste applicaties waren 


eenvoudige, in één stap verlopende transacties. 
Er werd later een ingewikkelder logica 


IE | : ontwikkeld. 
Open source DBMS- 1995 — ‚MySQL, PostgreSQL dl Opensource-DBMS-producten bieden veel van 
producten heden en andere producten | de functionaliteit van commerciële producten, 
At ln L EEn maar tegen lagere kosten. 
XML en webservices | 1998- XML, SOAP, WSDL, XML biedt enorme voordelen aan op het web 
‚heden | UDDI en andere gebaseerde applicaties. Is tegenwoordig heel 
[standaarden belangrijk. Zie hoofdstuk 12. 


Figuur 1-20 (vervolg) 


Samenvatting 


Een database heeft tot doel mensen te helpen gegevens bij te houden. Databases 
slaan gegevens op in tabellen, waarbij elke tabel gegevens bevat over iets anders. In- 
stanties van dat iets worden opgeslagen in de rijen van de tabellen en kenmerken van 
deze instanties worden opgeslagen in kolommen. Tabelnamen schrijven we in dit 
boek geheel in hoofdletters, kolomnamen in kleine letters maar met een hoofdletter 
aan het begin. Databases slaan gegevens en de relaties tussen deze gegevens op. De 
manier waarop gegevens in databases worden opgeslagen, is zo dat daaruit informa- 
tie kan worden geproduceerd. 

Figuur 1-5 laat veel belangrijke voorbeelden zien van databasetoepassingen. Da- 
tabases kunnen worden gebruikt door een enkele gebruiker, of door veel gebruikers 
tegelijk. Databases die veel gebruikers ondersteunen, vereisen speciale besturings- 
mechanismen om zeker te stellen dat het werk van de ene gebruiker niet in conflict 
komt met het werk van een andere gebruiker. 

Sommige databases hebben maar een paar gebruikers en omvatten maar een 
paar duizend rijen gegevens in enkele tabellen. Sommige grote databases daarente- 
gen ondersteunen duizenden gebruikers en omvatten vele miljoenen rijen in hon- 
derden tabellen. 

Microsoft Access is een low-endproduct dat veel van de onderliggende data- 
basetechniek van de gebruiker verbergt. Microsoft Access omvat onder de motorkap 
onderdelen voor applicaties, SQL en een DBMS. Microsoft Access-applicaties maken 
en verwerken formulieren, rapporten en query’s (zoekopdrachten). Ze halen gege- 
vens op en slaan deze op door SQL-statements door te geven aan het DBMS. SQL is 
een wereldwijd gebruikte taal voor databaseverwerking. 
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Een DBMS is een groot en ingewikkeld computerprogramma voor het maken, be- 
werken en beheren van een database. Softwareleveranciers verkopen licenties voor 
het gebruik van DBMS-producten. 

Microsoft Access is geen DBMS, maar meer een applicatiegenerator plus een 
DBMS. De applicatiegenerator bestaat uit deeltoepassingen die formulieren, rappor- 
ten en zoekopdrachten produceren. 

Grote databasesystemen voor bedrijven combineren applicaties en het DBMS 
niet op de manier zoals Microsoft Access dat doet. Applicaties zijn in plaats daar- 
van afzonderlijke programma's, die gescheiden blijven van elkaar en van het DBMS. 
Figuur 1-11 toont vier categorieën databasetoepassingen: client-serverapplicaties, 
webapplicaties, rapportageapplicaties en applicaties voor XML-webservices. 

De vijf populairste DBMS-producten zijn — in volgorde van kracht, mogelijkhe- 
den en complexiteit in het gebruik — Microsoft Access (eigenlijk Jet), MySQL, SQL 
Server, DB2 en Oracle. Jet en SQL Server worden verkocht door Microsoft, MySQL 

door Sun Microsystems/Oracle, DB2 door IBM en Oracle door Oracle Corporation. 

Een database is een zichzelf beschrijvende verzameling van geïntegreerde tabel- 
len. Dergelijke tabellen slaan gegevens en de relaties daartussen op. Een database 
bevat een beschrijving van zichzelf. Metagegevens zijn gegevens over gegevens. 
Databases bevatten metagegevens die de structuur van de database beschrijven. De 

meeste DBMS-producten slaan metagegevens op in de vorm van tabellen. Databases 
kunnen op drie manieren ontstaan: vanuit bestaande gegevens, voor nieuwe syste- 
men en door databases te herontwerpen. Normalisatie wordt gebruikt als leidraad 
voor het ontwerpen van databases op basis van bestaande gegevens. Er worden data- 
modellen gebruikt voor het maken van een blauwdruk op basis van de systeemeisen. 
Deze blauwdruk wordt later omgezet in een databaseontwerp. De meeste datamo- 
dellen worden gemaakt met het entiteit-relatiediagram. Het herontwerpen van data- 
bases is nodig als een bestaande database wordt aangepast om nieuwe of gewijzigde 
eisen te ondersteunen, of als twee of meer databases worden geïntegreerd. 

Met betrekking tot databaseverwerking zijn er twee rollen te onderkennen: ge- 
bruiker en databasebeheerder. Je kunt een gebruiker van een database/DBMS zijn, 
zoals een kenniswerker of een applicatieprogrammeur. Je kunt ook een database- 
beheerder zijn die de database zelf ontwerpt, bouwt en beheert. 

De geschiedenis van de databaseverwerking is samengevat in Figuur 1-20. 


Belangrijke termen 

bedrijfsdatabase databasemigratie 

CODSYL DBTG databaseapplicatie 

data databasebeheerder 

Data Language/l (DL/I) databasemanagementsysteem (DBMS) 
datamart databaseontwerp 

datawarehouse datamodel 

database entity-relationship (ER) datamodellering 
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foreign key (vreemde sleutel) 

gebruiker 

gegevens 

geïntegreerde tabellen 

informatie 

instantie 

kenniswerker 

kolom 

metadata 

normaalvorm 

normalisatie 

objectgeoriënteerd programmeren 
(OOP) 
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objectgeoriënteerd DBMS 
(OODBMS of ODBMS) 

primaire sleutel 

programmeur 

record 

relatie 

relationeel model 

relationele database 

rij 

Structured Query Language (SQL) 

tabel 

vreemde sleutel (foreign key) 

zelfbeschrijvend 


Oefeningen 


Welk type database wordt het meest gebruikt? 


Bedenk zelf een voorbeeld van twee gerelateerde tabellen. Gebruik de tabellen 
STUDENT en CIJFER uit Figuur 1-1 als een voorbeeld voor je tabellen. Geef de 
tabellen en kolommen namen volgens de in dit boek gebruikte conventies. 

Wat zijn de primaire sleutels in de tabellen die je bij vraag 3 hebt bedacht? 

Leg uit wat de relatie is tussen de twee tabellen die je bij vraag 3 hebt bedacht. 
Laat de twee tabellen uit vraag 3 zien zonder de kolommen die de relaties weer- 
geven. Leg uit waarom de twee tabellen minder nuttig zijn zonder de relaties. 
Beschrijf de termen gegevens en informatie. Leg uit wat het verschil is tussen deze 


Geef een voorbeeld van informatie die je zou kunnen bepalen op basis van de 
twee tabellen die je in het antwoord op vraag 3 hebt geleverd. 

Bedenk zelf een voorbeeld van een databaseapplicatie voor een enkele gebruiker 
en een databasetoepassing voor meerdere gebruikers, anders dan de in Figuur 


Welk probleem kan er optreden als een database door meer dan één gebruiker 


Geef een voorbeeld van een databaseapplicatie die honderden gebruikers en een 
zeer grote en ingewikkelde database heeft. Gebruik een voorbeeld dat niet in dit 


Wat is het doel van de grootste databases die door e-commercebedrijven zoals 


Waarin verschillen digitale dashboards en applicaties voor datamining van ap 


2. Watis het doel van een database? 
3% 
4. 
5. 
6. 
7e 
termen. 
8. 
9. 
1-5 genoemde. 
Io. 
wordt verwerkt? 
IL. 
hoofdstuk voorkomt. 
12. 
Amazon.com worden gebruikt? 
13. Wat doen e-commercebedrijven met deze databases? 
I4. 
plicaties voor transactieverwerking? 
I5. 


Leg uit waarom een kleine database niet noodzakelijk eenvoudiger is dan een 
grote. 
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16. Beschrijf de onderdelen uit Figuur 1-7. 

17. Wat zijn de functies van applicatieprogramma's? 

18. Wat is SQL? Waarom is SQL belangrijk? 

19. Waar is DBMS de afkorting van? 

20. Wat zijn de functies van het DBMS? 

21. Noem een aantal leveranciers van DBMS-producten. 

22. Geef een definitie van de term database. 

23. Waarom noemen we een database zelfbeschrijvend? 

24. Wat zijn metagegevens? Wat heeft deze term met een database te maken? 
25. Welk voordeel levert het opslaan van metagegevens in tabellen op? 


26. Noem de onderdelen van een database, naast de gebruikerstabellen en 
metagegevens. 


27. Is Microsoft Access een DBMS? Waarom, of waarom niet? 
28. Beschrijf de onderdelen van Figuur 1-10. 
29. Wat is de functie van de applicatiegenerator in Microsoft Access? 
30. Wat is de naam van de DBMS-engine in Microsoft Access? Waarom horen we 
maar zelden iets over deze engine? 
31. Waarom verbergt Microsoft Access belangrijke databasetechnologie? 
32. Waarom zou iemand ervoor kiezen de eigen DBMS-engine van Microsoft Ac- 
cess door SQL Server te vervangen? 
33. Noem de onderdelen van een databasesysteem voor bedrijven. 
34. Noem en beschrijf de vier categorieën voor databaseapplicaties. 
35. Hoe gaan databaseapplicaties te werk voor het ophalen en opslaan van 
databasegegevens? 
36. Noem de vijf DBMS-producten die we in dit hoofdstuk beschreven. 
37. Noem diverse consequenties van een slecht ontworpen database. 


38. Leg twee manieren uit voor het ontwerpen van een database op basis van be- 
staande gegevens. 


39. Wat is een datamart? 

40. Beschrijf in het algemeen het proces voor het ontwerpen van een database voor 
een nieuw informatiesysteem. 

41. Leg twee manieren uit voor het herontwerpen van databases. 

42. Wat betekent de term databasemigratie? 


43. Vat de diverse manieren samen waarop je met databasetechniek zou kunnen 
werken. 


44. Welke arbeidstaken voert een databasebeheerder uit? 
45. Welke arbeidstaken voert een databasegebruiker uit? 
46. Leg uit wat de gebieden in Figuur 1-18 betekenen. 


Projectvragen 


Je hebt een computer nodig waar Microsoft Access op is geïnstalleerd om de vol- 
gende projecten te kunnen uitvoeren. Lees bijlage A voordat je verdergaat, als je nog 
geen ervaring hebt met het werken met Microsoft Acces. 


24 


INLEIDING 


We geven in dit boek de tabelstructuur soms aan door de naam van een tabel te 
schrijven, gevolgd door de namen van de kolommen van die tabel tussen haakjes. 


47. 


48. 


49. 


50. 


51. 


52. 


Maak een nieuwe database met de naam Project Een en maak daarin de tabellen 
AFDELING en WERKNEMER met de volgende kolommen: 


AFDELING (Afdelingnaam, Kantoornummer, Telefoon) 
en 
WERKNEMER (Werknemernaam, E-mail, Afdelingnaam) 


Neem aan dat alle kolommen tekstgegevens bevatten en stel de lengte van elk 
tekstveld in op een toepasselijke waarde. 

Voeg minstens twee rijen toe aan de tabel AFDELING en minstens vijf rijen aan 
de tabel WERKNEMER. Zorg ervoor dat elke rij in de tabel WERKNEMER een 
geldige waarde heeft voor Afdelingnaam. 

Gebruik de wizard voor het maken van formulieren van Microsoft Access en 
maak een formulier dat alle gegevens uit beide tabellen bevat. Kies vervolgens 
AFDELING als je gevraagd wordt hoe je de gegevens wilt weergeven. Selecteer 
de standaardopties voor de overige vragen die de wizard stelt. Open het formu- 
lier en blader door de afdelingen. 

Gebruik de wizard voor het maken van rapporten van Microsoft Access en 
maak een rapport dat alle gegevens uit beide tabellen bevat. Kies vervolgens 
AFDELING als je gevraagd wordt hoe je de gegevens wilt weergeven. Selecteer 
de standaardopties voor de overige vragen die de wizard stelt. Druk het rapport 
af. 

Leg uit, met hetzelfde niveau aan detail als in dit hoofdstuk, wat er in project- 
vraag 3 en 4 onder de ‘motorkap’ van Microsoft Access gebeurt. Welke deel- 
toepassing heeft het formulier en het rapport gemaakt? Waar zijn de gegevens 
opgeslagen? Welke rol speelt SQL hier volgens jou bij? 

Mocht je eraan twijfelen of Microsoft Access werkelijk SQL gebruikt, ga dan 
als volgt te werk: open het formulier in de ontwerpweergave (klik op het pic- 
togram Beeld boven in het venster van Microsoft Access terwijl het formulier 
open is). Rechtsklik op de linkerbovenhoek van het subformulier (het gebied 
waarin de gegevens van WERKNEMER worden weergegeven). Klik op Eigen- 
schappen en selecteer het tabblad Gegevens. Klik op de knop met de drie punten 
naast Recordbron, die een dialoogvenster weergeeft dat je vraagt of je het venster 
Opbouwfunctie voor query’s wilt weergeven. Klik op Ja. Rechtsklik in het grijze 
gebied in het bovenste paneel van het venster SQL-instructie: opbouwfunctie 
voor query’s, dat daarop opent, en selecteer SQL. De SQL die Microsoft Access 
gebruikt voor het invullen van het subformulier wordt weergegeven. 
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Hoofdstuk 2 
Inleiding in Structured Query 
Language (SQL) 


In dit hoofdstuk zien we hoe gebruikers ad-hoc-query’s uitvoeren, wat in feite vragen 
zijn die te beantwoorden zijn met behulp van de gegevens uit een database. Een voor- 
beeld van een ad-hoc-query in gewoon Nederlands is: ‘Hoeveel mensen uit Antwerpen 
kochten onze witte theekopjes?’ Zulke query's heten ad hoc omdat ze door de gebrui- 
ker geformuleerd worden op het moment dat ze nodig zijn, in tegenstelling tot query’s 
die voorgeprogrammeerd zijn in een programma. 

Veel databasesystemen hebben hulpmiddelen om query’s te formuleren. Een per- 
soonlijke database als Microsoft Access gebruikt een manier die query by example 
(QBE) heet om het maken van ad-hoc-query’s te vereenvoudigen. 

In alle gevallen wordt (eventueel achter de schermen) gebruikgemaakt van de 
Structured Query Language (SQL), de universele querytaal voor relationele DBMS-pro- 
ducten. In dit hoofdstuk introduceren we SQL door SQL-query’s te maken en uit te laten 
voeren. In hoofdstuk 7 komen we terug op SQL, maar dan met het doel om databases 
te maken en er gegevens aan toe te voegen. 
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2.1 Swaen Buitensport 


Voor ons werk in dit hoofdstuk maken we gebruik van de gegevens van Swaen Bui- 
tensport, een fictief bedrijf dat uitrusting verkoopt voor recreatieve buitensporten in 
vijftien winkels in diverse landen, waaronder de USA. Het bedrijf verkoopt ook ar- 
tikelen over internet via een webwinkel en via postorder. Alle verkoopgegevens wor- 
den opgeslagen in een door Oracle ontwikkelde database, die je in Figuur 2-1 ziet. 


Winkel 2 


0 


Í Re, 
Winkel 15 


Oracle 
Verkoop 
Gegevens- 
bestand 


De Extractie van de 
Gegevens van de Verkoop 
van de detailhandel 


Webwinkel/- 
internetverkoop 


Internetklanten 


N/e 


Postorderklanten 


Verkoop Het 
Gegevens- 
bestand van 

de extractie 


Figuur 2-1 Gegevens voor winkelverkoop extraheren voor Swaen Buitensport 


2.1.1 Verkoopgegevens extraheren 

De marketingafdeling van Swaen Buitensport wil een analyse uitvoeren van de ver- 
koop via winkels. De marketinganalisten vragen de IT-afdeling daarom verkoopgege- 
vens uit de werkdatabase te extraheren. Ze hebben niet alle verkoopgegevens nodig 
voor het uitvoeren van hun marketingstudie. Ze willen alleen de in Figuur 2-2 ge- 
toonde tabellen en kolommen hebben, en ze willen hun analyse uitvoeren met be- 
hulp van Microsoft Access 2007. 

In Figuur 2-2 en Figuur 2-3 zie je welke drie tabellen nodig zijn: BESTELLING, 
BESTELLING-_ITEM en ARTIKEL. De tabel BESTELLING bevat gegevens over elke 
bestelling, de tabel BESTELLING. ITEM bevat gegevens over elk item in een bestel- 
ling en de tabel ARTIKEL bevat gegevens over elk artikel dat Swaen Buitensport 


verkoopt. 
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2.1.2 De gegevens in BESTELLING 

Zoals je in Figuur 2-2 en Figuur 2-3 ziet, bevat BESTELLING kolommen voor Bestel- 
lingnummer, Winkelnummer, Postcode (de postcode van de winkel die de bestelling 
aanneemt), Maand, Jaar en Bestellingtotaal. 


ARTIKEL 
V Artikelnummer 
Artikelomschrijving 
Afdeling 
Inkoper 


Aantal 


BESTELLING ITEM 
Y Bestellingnummer 
U Artikelnummer 


Stukprijs 
Totaalprijs 


BESTELLING 


Y Bestellingnummer 
Winkelnummer 
Postcode 
Maand 
Jaar 
Bestellingtotaal 


Figuur 2-2 Tabellen en relaties van de geêxtraheerde verkoopgegevens 


[Tabel 


OEE ien _[gegevenstype 
| BESTELLING : |Bestellingnummer Integer 
# Winkelnummer Integer _ 
| ___{ Postcode | character (9) 
[ Dun | Maand. pl Character (12) 
Le _ 6 laar Integer 
pn Bestellingtotaal Currency 
| BESTELLING ITEM a Bestellingnummer _ {Integer 
[Artikelnummer Integer 


Hoeveelheid Integer 
Prijs Currency 
| Totaalprijs Currency 


Integer 


| ARTIKEL Artikelnummer 
HF 


Í Artikelomschrijving 


Character (35) 


Character (30) 


Afdeling 


Inkoper 
Figuur 2-3 De indeling van de geëxtraheerde gegevens 


Voorbeeldgegevens voor BESTELLING zie je in Figuur 2-4. Dit uittreksel omvat al- 
leen gegevens voor in winkels verkochte artikelen. Alle gegevens over op andere ma- 
nieren verkochte artikelen (en geretourneerde artikelen en andere aan de verkoop 
gerelateerde transacties) worden tijdens het extractieproces verwijderd. 

Bovendien worden tijdens het extractieproces slechts enkele kolommen uit de 
oorspronkelijke gegevens gekozen. De verkooppunt-applicatie (ook wel bekend als 
Point Of Sale- of POS-applicatie) en andere applicaties verwerken veel meer gege- 
vens dan je hier ziet. De ruwe bestelgegevens in de Oracle-database slaan de datum 
bijvoorbeeld op in de datumindeling DD-MM-JJJJ (dus 22-10-2011 voor 22 oktober 
2011). Het extractieprogramma zet deze datum om in de waarden van Maand en Jaar 
die de marketingafdeling wil hebben. Dergelijke filteringen en gegevenstransforma- 
ties zijn gebruikelijk bij het proces van het extraheren van gegevens. 
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ARTIKEL F p A 
Artikelnummer Artikelomschrijving Ee, Afdeling Inkoper 
100100 Standaard SCUBA, geel Watersport PeterJansen | 
100200 Standaard SCUBA, magenta _| Watersport _|Peterjansen | 
101100 Duikmasker, small, helder | watersport - Najma Barends | 
101200 Ouikmasker, medium, helder $ _[werersport led | Najma Barends | 
201000 Halvekoepeltent ____|Camping _ |Charlottetaan | 
202000 Grondzeil halvekoepeltent {Camping _____{ Charlotte Laan _ ad | 
301000 Lichtgewicht klimharnas {Klimmen Johan Martens | 
302000 Karabijnsluiting, ovaal klimmen John Johan Martens | 
BESTELLING wd je 
Bestellingnummer |__ Winkelnummer | Postcode L Maand | Jaar | Bestellingtotaal 
10 |_98110 december | 2008 | €445,00 
20 | 02335 |december | 2008 | €310,00 | 
10 |_og110_|janvari | 2009 | € 480,00 | 


BESTELLING ITEM 
Artikelnummer el Stukprijs | Totaalprijs | 
100200 1 €300,00 _|_ € 300,00 
101100 4 €50,00 [ €200,00 
101100 2 cs0,00 | _c100,00 
101200 2 €50,00 | c100,00 

1 

1 


Bestellingnummer 


101200 €50,00 | € 50,00 
201000 €300,00 | €300,00 
202000 1 €130,00 | _C130,00 


Figuur 2-4 Voorbeeldgegevens uit het uittreksel van de verkoopgegevens 


2.1.3 De gegevens in BESTELLING ITEM 
Zoals je in Figuur 2-2 en Figuur 2-3 ziet, heeft de tabel BESTELLING. ITEM ko- 
lommen voor Bestellingnummer, Artikelnummer, Aantal, Stukprijs en Totaalprijs 
(welke gelijk is aan Aantal * Stukprijs). De tabel BESTELLING. ITEM slaat dus een 
uittreksel op van de items die per bestelling zijn verkocht. Er is een rij in de tabel 
voor elk Artikelnummer in een bestelling. Je kunt deze tabel beter begrijpen als je 
aan een verkoopbon denkt, zoals je die in een winkel krijgt. Die bon bevat gegevens 
over één order. De bon bevat basisgegevens zoals de orderdatum en de totaalprijs van 
de order, en bevat daarnaast een regel voor elk item dat je kocht. De rijen in de tabel 
BESTELLING ITEM komen overeen met de regels op een dergelijke bon. 
Bestellingnummer is gerelateerd aan Bestellingnummer in de tabel BESTEL- 
LING. Artikelnummer is gerelateerd aan Artikelnummer in de tabel ARTIKEL (die 
we in de volgende paragraaf bespreken). Stukprijs is de prijs van elk item en To- 
taalprijs is gelijk aan het aantal maal de prijs (Aantal * Stukprijs). Je ziet de BE- 
STELLING_ITEM-gegevens onder in Figuur 2-4. De eerste rij is gerelateerd aan 
bestelling 3000 en aan Artikelnummer 1oo20o, die is aangeschaft voor 300, met de 
Totaalprijs 300. De tweede rij is gerelateerd aan bestelling 2000. Er werden in die 
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rij 4 items van rorroo aangeschaft voor so per stuk en de Totaalprijs is 4 * so, ofte- 
wel 200. Deze indeling is gebruikelijk voor items in bestellingen — je komt deze ook 
weer tegen in hoofdstuk 5 en 6. Daarin maak je een datamodel voor een complete 
bestelling, waarna je de database ontwerpt voor dat datamodel. 


Opmerking 

Je zou verwachten dat het totaal van Totaalprijs voor alle rijen van een gegeven bestelling identiek is 
aan Bestellingtotaal in de tabel BESTELLING. Dat is echter niet het geval. De som van de Totaalprijs is 
bijvoorbeeld 300 + 100 + 50, oftewel 450, voor bestelling 3000. Bestellingtotaal is echter 480 voor deze 
bestelling. Het verschil wordt veroorzaakt door het feit dat Bestellingtotaal de btw, de verzendkosten en 
andere onkosten omvat die niet in het uittreksel uit de gegevens voorkomen. 


2.1.4 De tabel ARTIKEL 

Zoals je in Figuur 2-2 en Figuur 2-3 ziet, heeft de tabel ARTIKEL kolommen Artikel- 
nummer, Artikelomschrijving, Afdeling en Inkoper. Artikelnummer is een in- 
tegerwaarde die een bepaald product identificeert dat door Swaen Buitensport 
wordt verkocht, bijvoorbeeld Artikelnummer rootroo komt overeen met een gele 
standaardscubatank. 

Artikelomschrijving bevat een korte tekstbeschrijving van elk item. Afdeling en 
Inkoper identificeren de afdeling en de persoon die verantwoordelijk is voor het aan- 
schaffen van het product. Deze kolommen zijn, net als bij de andere tabellen, een 
deelverzameling van de in de werkdatabase opgeslagen Artikel-gegevens. 


2.1.5 Gegevensuittreksels komen veel voor 

Voordat we verdergaan, moet je begrijpen dat het zojuist beschreven proces voor het 
extraheren van gegevens meer is dan alleen een theoretische oefening. Honderden 
bedrijven over de hele wereld zijn op dit moment bezig soortgelijke databases met 
uittreksels te maken zoals Swaen Buitensport zojuist maakte. In de volgende pa- 
ragrafen van dit hoofdstuk maak je op een praktische wijze kennis met de manier 
waarop SQL-statements worden opgesteld om gegevens te extraheren. 


2.2 De achtergrond van SQL 


SQL werd tegen het einde van de jaren zeventig ontwikkeld door IBM Corporation 
en in 1986 door het American National Standards Institute (ANSI) benoemd tot een 
Amerikaanse nationale standaard en in 1987 door de International Organization of 
Standardization (ISO). In 1989 en 1992 kwamen nieuwe versies uit. De hier ge- 
presenteerde versie is op die standaard gebaseerd, die soms ook wel SQL-92 wordt 
genoemd. Een nieuwere versie uit 1999, ook wel SQL3 genaamd, omvat een aan- 
tal objectgeoriënteerde ideeën. Deze versie kreeg weinig aandacht van commerciële 
DBMS-leveranciers en is praktisch gezien niet van belang voor de databaseverwer- 
king. We gaan er in dit boek niet verder op in. 

SQL is geen volledige programmeertaal zoals Java of C#. SQL wordt in plaats 
daarvan een datasubtaal genoemd, omdat deze taal alleen statements kent voor het 
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definiëren en verwerken van databasegegevens en databasemetagegevens. Je kunt 
SQL-staternents op allerlei verschillende manieren gebruiken. Je kunt ze recht- 
streeks ter verwerking aan het DBMS doorgeven. Je kunt SQL-statements gebruiken 
in client-serverapplicaties, webapplicaties, rapportapplicaties, enzovoort. 

SQL is heel precies en daarom is voor het programmeren in SQL enige vaardig- 
heid essentieel. Alle DBMS-producten werken tegenwoordig met SQL. Een DBMS 
als Microsoft Access verbergt de SQL van de gebruiker. Andere DBMS'’en zoals Ora- 
cle, DB2, SQL Server en MySQL vereisen dat je SQL kent. Alle gegevensverwerking 
wordt met deze producten uitgedrukt in SQL. 

SQL-statements worden gewoonlijk onderverdeeld in twee categorieën: 
statements voor het manipuleren van gegevens — data manipulation language of 
DML-statements, 


statements voor het definiëren van gegevens — data definition language of 
DDL-statements. 


DML-statements worden gebruikt voor het zoeken naar en wijzigen van gegevens, 
terwijl DDL-statements worden gebruikt voor het maken van tabellen, relaties en an- 
dere structuren. Dit hoofdstuk bespreekt alleen DML-statements voor het opvragen 
van gegevens. De resterende DML-statements voor het invoegen, wijzigen en verwij- 


deren van gegevens bespreken we in hoofdstuk 7. Je leert in dat hoofdstuk ook SQL- 
DDL-statements kennen. 


2.3 _SELECT/FROM/WHERE 


Deze paragraaf introduceert de fundamentele basis voor SQL-querystatements. We 
bespreken eerst deze basisstructuur en daarna zie je hoe je SQL-statements door- 
geeft aan Microsoft Access. Je kunt de SQL-statements dan, als je dat wilt, uitvoeren 


terwijl je de bespreking ervan in dit boek leest. Zie paragraaf 2.4 voor het uitvoeren 
van SQL met Microsoft Access. 


2.3.1 Specifieke kolommen lezen uit een enkele tabel 
We beginnen heel eenvoudig. Stel dat je alleen de waarden uit de kolommen Afde- 


ling en Inkoper van de tabel ARTIKEL wilt ophalen. Het volgende SQL-statement zal 
deze gegevens lezen: 


SELECT Afdeling, Inkoper 
FROM ARTIKEL; 


Dit statement zal het overzicht van Figuur 2-5 opleveren, nadat het DBMS dit state- 
ment heeft verwerkt (op basis van de gegevens uit Figuur 2-4). 
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Afdeling | Inkoper 
Watersport Peter Jansen 
| Watersport [peter Jansen 
| Watersport Najma Barends 
| watersport Najma Barends 
Camping Charlotte Laan 5 
Camping [Charlotte Laan 
Klimmen Johan Martens A 
[Klimmen Johan Martens 


Figuur 2-5 Resultaat van SELECT-statement 


SQL-statements werken op tabellen. Ze beginnen met een tabel, verwerken die tabel 
en brengen de resultaten daarvan dan in de vorm van een andere tabel. Zoals je later 
in dit hoofdstuk zult zien, kunnen sommige SQL-statements meer tabellen tegelijk 
verwerken. De output van een SQL-statement is echter altijd een enkele tabel, onge- 
acht het aantal verwerkte tabellen. 

Merk ook op dat SQL-statements met een puntkomma worden afgesloten. Deze 
puntkomma wordt vereist door de standaard SQL-92. Sommige DBMS-producten 
zullen het je weliswaar toestaan de puntkomma weg te laten, maar andere doen dat 
weer niet. Je kunt er dus beter een gewoonte van maken om SQL-statements altijd 
met een puntkomma af te sluiten. 

De volgorde van de kolommen in de tabel met resultaten wordt bepaald door de 
volgorde van de kolomnamen in het SELECT-statement. Als we Inkoper en Afdeling 
in het SELECT-statement omwisselen, zullen deze dus ook in de uitvoertabel worden 
omgewisseld. Het volgende SQL-statement produceert dus de tabel van Figuur 2-G: 


SELECT Inkoper, Afdeling 
FROM ARTIKEL; 


Inkoper Afdeling 


Peter Jansen Watersport 
Peter Jansen Watersport 


Najma Barends 
Najma Barends 
Charlotte Laan 
[charlotte Laan 
Johan Martens 
johan Martens 


Watersport 
Watersport 
Camping 
Camping 


Klimmen 
Klimmen 


Figuur 2-6 Resultaat na wisseling van kolommen Inkoper en Afdeling 


Merk op dat de rijen zijn gedupliceerd in deze resultaten. De gegevens in de eerste 
en tweede rij zijn bijvoorbeeld identiek. We kunnen de duplicaten elimineren door 
het sleutelwoord DISTINCT te gebruiken: 
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SELECT DISTINCT Inkoper, Afdeling 
FROM ARTIKEL ; 


Het resultaat daarvan is te zien in Figuur 2-7. 


Afdeling 
Peter Jansen Watersport 
Najma Barends Watersport 


Charlotte Laan 


Johan Martens 


Figuur 2-7 Resultaat na eliminatie van duplicatie 


Klimmen 


Opmerking 

De reden dat SQL dubbel voorkomende rijen niet automatisch verwijdert, is dat het erg veel tijd kan 
kosten dat te doen. Om te zien of rijen vaker voorkomen moet elke rij met elke andere rij worden 
vergeleken. Als er 100.000 rijen in een tabel zijn kan dat veel tijd kosten. 


Stel dat we alle kolommen van de tabel ARTIKEL willen bekijken. We kunnen dat als 
volgt doen door alle kolomnamen te noemen in het SELECT-statement: 


SELECT Artikelnummer, Artikelomschrijving, Afdeling, Inkoper 
FROM ARTIKEL; 


Het resultaat is te zien in Figuur 2-8. 


Deze tabel bevat alle rijen en alle kolommen van de tabel ARTIKEL. Hetzelfde resul- 


taat kun je krijgen met een kortere versie: het sterretje * is een afkorting voor ‘alle 
kolommen’: 


SELECT * 
FROM ARTIKEL; 


Het resultaat is opnieuw Figuur 2-8. 
2.3.2 Specifieke rijen lezen uit een enkele tabel 
Stel dat we alle kolommen van de tabel ARTIKEL willen hebben, maar alleen de rijen 
voor de afdeling Watersport willen zien. We kunnen dat resultaat als volgt krijgen 
door de WHERE-clausule te gebruiken: 

SELECT * 

FROM ARTIKEL 

WHERE Afdeling = ‘Watersport’; 


Het resultaat van dit SQL-statement is te zien in Figuur 2-9. 
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| a ARKE 
| Artikelnummer | Artikelomschrijving È Afdeling li inkoper 
_ 100100 | standaard SCUBA, geel_______| Watersport _ Peter Jansen 
__100200 | standaard SCUBA, magenta Pe | watersport e | Peter Jansen 
| ___101100 Duikmasker, small, helder E Si Watersport Najma Barends 
LS 101200 | Duikmasker, medium, helder | Watersport ä |Najma Barends | 
L 201000 | Halvekoepeltent {Camping | Charlotte Laan 
| 202000 | Grondzeil halvekoepeltent __ ‚Camping | charlotte Laan 
| 301000 Ps Lichtgewicht klimharnas | Klimmen __|Johan Martens 
L____302000 | Karabijnsluiting, ovaal E Klimmen Johan Martens 
Figuur 2-8 Resultaat van SELECT-statement 
| Artikelnummer |_ s _Artikelomschrijving 5 Ĳ Afdeling Inkoper el 
| __ 100100 El Standaard SCUBA, geel ‚Watersport Peter Jansen | 
__100200 | Standaard SCUBA, magenta Watersport |Peter jansen __ | 
101100 __{ Duikmasker, small, helder Watersport Najma Barends 
101200 | Duikmasker, medium, helder [watersport Najma Barends | 


Figuur 2-9 Resultaat WHERE-clausule 


De vergelijkingswaarden moeten in een WHERE-clausule tussen enkele aanhalings- 
tekens (“) worden geplaatst als de kolom tekst- of datumgegevens bevat. De verge- 
lijkingswaarden hoeven echter niet tussen aanhalingstekens te staan als de kolom 
numerieke gegevens bevat. We zouden dus het volgende schrijven als we alle Artikel- 
nummer-rijen zouden zoeken met een waarde groter dan 200.000: 


SELECT 
FROM ARTIKEL 
WHERE Artikelnummer > 200000; 


Het resultaat staat in Figuur 2-10. 


Artikelomschrijving Afdeling 
201000 Halvekoepeltent 


Charlotte Laan 


202000 Grondzeil halvekoepeltent Camping Charlotte Laan 
301000 Lichtgewicht klimharnas Klimmen Johan Martens 
302000 Karabijnsluiting, ovaal Klimmen Johan Martens 


Figuur 2-10 Resultaat zoekactie >200000 


Je ziet dat de vergelijkingswaarde niet tussen aanhalingstekens staat. Merk ook op 
dat er geen komma of punt wordt gebruikt in de numerieke waarde. 


2.3.3 Specneke kolommen en specifieke rijen lezen uit een enkele 
tabe 


We hebben tot dusver specifieke kolommen en alle rijen geselecteerd, of alle kolom- 
men en specifieke rijen. We kunnen deze handelingen combineren om specifieke 
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kolommen en specifieke rijen te selecteren door de kolommen te noemen die we 
willen hebben en de WHERE-clausule te gebruiken. We geven bijvoorbeeld het vol. 
gende op om de Artikelomschrijving en Afdeling op te halen van alle producten in 
de afdeling voor klimsporten: 


SELECT Artikelomschrijving, Afdeling 
FROM ARTIKEL 


WHERE Afdeling = 'Klimmen'; 


Het resultaat staat in Figuur 2-11. 


Artikelomschrijving 


Lichtgewicht klimharnas 


Afdeling 
Klimmen 


Karabijnsluiting, ovaal Klimmen 


Figuur 2-11 Resultaat Artikelomschrijving gekoppeld aan Afdeling Klimmen 


SQL vereist niet dat de in de WHERE-clausule gebruikte kolom ook in de lijst 
van kolommen van SELECT voorkomt. We kunnen dus ook het volgende opgeven: 


SELECT Artikelomschrijving, Inkoper 
FROM ARTIKEL 
WHERE Afdeling = 'Klimmen'; 


waarbij de kolom Afdeling niet in de lijst van kolommen van SELECT voorkomt. Het 
resultaat is te zien in Figuur 2-12. 


Artikelomschrijving |__inkoper | 
Lichtgewicht klimharnas Johan Martens 


Karabijnsluiting, ovaal Johan Martens 


Figuur 2-12 Resultaat SELECT zonder Afdeling 


Opmerking 
Een DBMS staat toe om een volledig SQl-statement op één regel te schrijven. Het is echter gebruikelijk 


een SQL-statement voor de overzichtelijkheid over meerdere regels te verdelen. Deze conventie gebruiken 
wij dan ook in dit boek. 


2.4 SQl-statements aan het DBMS doorgeven 


Het is nuttig te laten zien hoe je SQL-statements aan een DBMS doorgeeft, voordat 
we met SQL verdergaan. Je kunt de SQL-statements dan zelf intypen en uitvoeren 
terwijl je de toelichting leest. 
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Opmerking 

Je kunt SQL leren zonder de query’s in een DBMS uit te voeren. Je hoeft je geen zorgen te maken als je 
om wat voor reden dan ook geen Microsoft Access (of een ander DBMS) mocht hebben. Het is echter wel 
zo dat SQL-statements makkelijker zijn te volgen en te onthouden als je de SQL kunt uitvoeren terwijl je 
deze leest. 


Hoe je de SQL-statements precies doorgeeft, is afhankelijk van het DBMS. We zullen 
in de volgende paragraaf toelichten hoe dat gaat met Microsoft Access 2007. 


2.4.1 Over SQL-89, SQL-92 en Microsoft Access 2007 

Om de SQL-opdrachten uit dit hoofdstuk te kunnen uitvoeren, heb je een compu- 
ter nodig waarop Microsoft Access 2007 is geïnstalleerd. Ook heb je een Microsoft 
Access-database nodig die de tabellen en voorbeeldgegevens uit Figuur 2-4 bevat. 

Je kunt de database, tabellen en gegevens uit Figuur 2-4 op twee manieren krij- 
gen. Je kunt de Microsoft Access-database met de naam SwaenBuitensport down- 
loaden van de website bij dit boek op www.pearsoneducation.nl. 

Je kunt ook zelf een eigen database maken en daar de tabellen en gegevens uit 
Figuur 2-4 aan toevoegen. Bijlage A geeft aan hoe dat in zijn werk gaat. 


Voor we verdergaan moeten we eerst even wijzen op een eigenaardigheid in Micro- 

soft Access 2007. Zoals je in paragraaf 2.2 hebt kunnen lezen bestaan er verschil- 

lende versies van SQL. Wij baseren ons op SQL-92, maar helaas is de defaultversie 

van Access niet SQL-92 maar SQL-89. Beide versies verschillen nogal van elkaar, het 

is dus belangrijk dat je Access instelt op de juiste versie. Dat doe je als volgt: 

* open Microsoft Access 2007; 

* open eventueel de database waarmee je wilt werken; 

«klik op de Microsoft Office-knop; 

+ klik onder in de rand van het venster op ‘Opties voor Access’; 

«klik op ‘Ontwerpfuncties voor objecten’; 

+ zet een of zo mogelijk twee vinkjes onder ‘Met SQL Server compatibele syntaxis 
(ANSI 92)’. 


Vanaf dit moment zullen de huidige database die je hebt geopend (als je er tenmin- 
ste een geopend hebt) en nieuwe databases met SQL-92 werken. Zie Figuur 2-13. 


2.4.2 SQL verwerken in Microsoft Access 

Om SQL-opdrachten te kunnen geven, moet je eerst een database in Microsoft 
Access openen. Lees zo nodig eerst nog de vorige paragraaf. 

«Open de database SwaenBuitensport.accdb. 

«Verifieer of Access gebruikmaakt van SQL-92 (zie Figuur 2-13). 


Aan de linkerkant van het scherm (zie Figuur 2-14) staan in het navigatievenster de 
namen van de tabellen. Behalve BESTELLING, BESTELLING ITEM en ARTIKEL 
die je uit Figuur 2-3 en Figuur 2-4 kent, zijn er nog twee tabellen (VOORRAAD en 
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Opties voor. Access 


* Pepu'ar PA | 


“il Opties aanpassen voor het maken en wijzigen van databaseobjecten in Access 
‚ Huidige database 3 


Gegevensbiad Tabelontwerp 


a | 
Wekeerptoncties voor objecten | 


Standaardveidtype 


Centroie Standaardlengte van jebsteelden: 


Geavanceerd Standaardlengte van pumenzke velden:  Langt integer bs 


pz mai steutei code getal 
aanpassen =utolndes bij importeren maten 1dsteutel code, ge 


102} Engppen voor byserkopties voor eigenschappen weergeven 
Invoegtoepassingen 


vertrauwenscentrum Queryontwerp 


Informatiebronnen Tabelnamen weergeven 
m| alle velden weergere 
Autoloin acweren 

Lettert,pe vaor het query; ontvee 


Lettertype:  Segae Ul 


Grootte 8 v 


Met SQL Server compatibele 17 


2 Deze datanase 


1 stansard voor nieuwe databases 


ntans (allS1 92} 


Formutieren/rapporten 


Werking van seiectiekader 
@ 


{ ©) Gedeentelyk omsiurten 
| ©) Yoredig omsluten 


Formutersjabtoon: Hormaal 
Ie Rapportsjablaon. _\Normaal 


mn) Altijd gebeurtenisprocedures gebruiken 


v 


Figuur 2-13 Venster Opties voor Access 


WINKEL) die we in dit hoofdstuk niet zullen gebruiken, maar die nodig zijn voor het 
beantwoorden van de herhalingsvragen aan het einde van het hoofdstuk. 


» Klik op het tabblad Maken. 
*_Klik op de knop Queryontwerp. 


Er wordt een tabblad met de naam Query1 zichtbaar en het venster ‘Tabel weer- 
geven’ met de namen van de tabellen. 


Sluit het venster ‘Tabel weergeven’. Het scherm ziet er nu uit als in Figuur 2-15. 


Merk op dat de tab Ontwerpen nu actief is. In het scherm van Figuur 2-15 kun je 


QBE-opdrachten (Query by Example) invoeren. Wij zullen dat niet doen omdat we 
zelf de query’s gaan schrijven. 


2.4.3 Een queryvenster openen en een query uitvoeren 
Om een query te kunnen maken open je eerst een queryvenster: 
« Klik (in de tab Ontwerpen) helemaal links op de knop SQL. Het Queryr-venster 


schakelt over naar de SQL-weergave en in het venster staat alvast een stukje Yan 
een opdracht: SELECT. 
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(Es) ed ° sl EWaenSutenrpart C Access 2007) - Mierosoit Access ie dekd 
Pm Start azen Euteme gegeven: Muipmddeten var dstabare: 
4 ents rie velie - ha E tou h 4 id 2 Eee 
da B AIEE B t SP speting <1 tso gr . 
7 Ji a ze X werwgderen ze : 8 ccd. 
mer Hemverd " tettertjpe Tekst ret opstaan ee so Zoeken 


| ze Access-objecten all > 
_ Tebeilen 2 
‚ARKEL 

D eesreuuns 


BESTELLING mTEr1 


zl 
D voorraso 
a 


| 
| 
| 
| 


Sereen ” EN 
Figuur 2-14 De database Swaen Buitensport 


+ _ Vul dit commando aan zodat het er als volgt uitziet: 


SELECT Afdeling, Inkoper 
FROM ARTIKEL; 


* Klik op de knop Uitvoeren (de knop met het uitroepteken) om de query te laten 
uitvoeren. Het resultaat zie je in Figuur 2-16. 


2.4.4 Een query bewaren 

Je kunt een query bewaren om hem later weer te gebruiken of te wijzigen: 

Klik op de knop Opslaan. Er verschijnt een dialoogvenster waarin je de naam van 
de query kunt invoeren. 

+ Typ als naam in QueryHoz2-or en klik op OK. 

«Sluit het queryvenster door op het kruisje rechtsboven in het venster te klikken. 


Op dit punt aangekomen kun je alle query’s die je vindt in paragraaf 2.3.1 tot en 


met paragraaf 2.3.3 invoeren en laten uitvoeren. Bewaar elk van de query’s als 
QueryHo2-##, waarbij ## staat voor een nummer van oa tot en met og. 
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z Pr : Huiamuadesen vaer zoer s 
Es d 
4 ant eseen terne zegent muperideien vaar afaene: Ort 
EL 
sql % si ; 
E TE Tabesanen 
aregnt Ren 


Sj Parameters 


en JP eri EN 


2 semen 
A eesmauris 

TJ eesrenapss men 
TD voorrs0 
IJ vesn 


| CR u] k 
Í ver 

\ Tabel 

| Sorteervolgorde 


| 
| 


> 


\ weergeven 0 
i Craens Kaa 
ct 
Gereed > E 
Figuur 2-15 Het QBE-venster 
(Cs) | a Ad SmsenBaterspon : Datsbase (Access 2007) - Microsoft 
ef! Start , Maten  Brtemegegeremi  Momiddelen soor databaies 
k/ 5 A Caren 3 LOA en pe = Meurs E Totalen 
on) d B 4 ute s A Ie hers Ml opsaan GF Spering 
pe . ater 
JA RE 4e wernielisen” | XV rant Treerr 
n Weme 7 


verenigt 


= en EVEN, re S 
Ale accesschyecten vc [DP Qoeyi 
Afdeling - 


Tabellen 2 | Inkoper 
3 ann |: tersocr. ASSE 
D esters IJ Watersport _ Peterlansen 
2 eesrturrs.ros Watersport _Najma Barends 


EER \|_waterspon _ Najma Barends 
Te | Camping Charlotte Laan 
ME: | ‚Camping Charlotte laan 
| Klimmen Marc Appels 
ij Kmmen Marc Appels 
Î * 


Figuur 2-16 Resultaat query 


HUMLOCK se 4 


2.5 Verder met SQL voor het zoeken in een enkele tabel 


In deze paragraaf kom je wat uitgebreidere query's tegen voor het verwerken van een 
enkele tabel. Je zult zien hoe krachtig SQL kan zijn voor het zoeken in databases en 
voor het genereren van informatie op basis van bestaande gegevens. De getoonde 
uitvoer is gemaakt met SQL Server — andere DBMS-producten leveren een soortge- 


lijke uitvoer. 
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2.5.1 De resultaten sorteren 

De volgorde van de rijen die een SQL-statement produceert is willekeurig en wordt 
bepaald door de programma’s onder de motorkap van elk DBMS. Wil je dat het 
DBMS de rijen in een bepaalde volgorde weergeeft, dan kun je de clausule ORDER 
BY gebruiken. Het volgende SQL-statement levert het resultaat van Figuur 2-17 op. 


SELECT A 
FROM BESTELLING ITEM 
ORDER BY Bestel lingnummer; 


Bestellingnummer Artikelnummer Aantal |_ Stukprijs teal | 
1000 201000 [a 1 € 300,00 € 300,00 
1000 | 202000 1 € 130,00 € 130,00 
_2000 101100 4 € 50,00 | € 200,00 
2000 sl 101200 2 € 50,00 € 100,00 
3000 100200 ik € 300,00 € 300,00 
3000 101100 |_2 | €50,00 | €100,00 | 
_3000 101200 1__| €50,00 € 50,00 


Figuur 2-17 Resultaat ORDER BY 


We kunnen op twee kolommen sorteren door een tweede kolomnaam toe te voegen. 
De volgende code sorteert bijvoorbeeld eerst op Bestellingnummer en dan op Stuk- 
prijs binnen Bestellingnummer: 


SELECT * 
FROM BESTELLING ITEM 
ORDER BY Bestellingnummer, Stukprijs; 


Het resultaat staat in Figuur 2-18. 


Artikelnummer | Aantal |_stukprijs_| Totaalprijs 


1 
201000 1 
€ 100,00 
101100 4 € 50,00 
101200 € 50,00 € 50,00 
101100 


Figuur 2-18 Resultaat sortering op twee kolommen 


Bestellingnummer 


€ 300,00 


Zouden we de gegevens op Stukprijs en dan op Bestellingnummer willen sor- 
teren, dan zouden we de volgorde van deze kolommen omdraaien in de ORDER 
BY-clausule: 
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SELECT A 
FROM BESTELLING ITEM 
ORDER BY Stukprijs, Bestellingnummer; 


Merk op dat Microsoft Access eurotekens toont in de uitvoer van valutagegevens. 
Niet alle DBMS-producten doen dat. 

Rijen worden standaard gesorteerd in oplopende volgorde. Voeg het sleutelwoord 
DESC (van het Engelse woord descending, dat aflopend betekent) toe achter de kolom- 
naam als je in aflopende volgorde wilt sorteren. Je kunt dus het volgende opgeven 


om eerst in aflopende volgorde op Stukprijs te sorteren en dan in oplopende volg: 
orde op Bestellingnummer: 


SELECT ® 
FROM BESTELLING ITEM 
ORDER BY Stukprijs DESC, Bestellingnummer ASC; 


Het resultaat zie je in Figuur 2-19. 


Bestellingnummer 
1000 201000 € 300,00 €300,00 | 


3000 100200 € 300,00 € 300,00 


1 
202000 €130,00 
2000 101200 


Artikelnummer | Aantal 


Stukprijs [ Totaalprijs | 


€ 130,00 


2 €50,00 | c100,00_ 
101100 €50,00 | €200,00 
1_| €sooo | 5000 | 
300 | sono | 2 | esooo | e10000 


Figuur 2-19 Resultaat aflopende volgorde Stukprijs en oplopende volgorde Bestellingnummer 


Het was niet echt nodig het sleutelwoord ASC (van het Engelse woord ascending, 
dat oplopend betekent) op te geven in het voorgaande SQL-statement, want de stan- 


daardvolgorde is al oplopend. Het volgende SQL-statement doet dan ook precies 
hetzelfde: 


SELECT * 
FROM BESTELLING ITEM 
ORDER BY Stukprijs DESC, Bestellingnummer ; 


2.6 Opties voor WHERE-clausules 
SQL kent een aantal opties voor WHERE-clausules die de kracht en het nut van de 


SQL aanzienlijk vergroten. We bespreken hier drie opties: samengestelde clausules, 
bereiken en jokertekens. 
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„6.1 Samengestelde WHERE-clausules 

SQL-WHERE-clausules kunnen meer voorwaarden omvatten door de operators 
AND, OR, IN en NOT IN te gebruiken. We kunnen bijvoorbeeld het volgende schrij- 
ven als we alle rijen in ARTIKEL willen vinden die een Afdeling met de naam Water- 
sport en een Inkoper met de naam Najma Barends bevatten: 


SELECT & 

FROM ARTIKEL 

WHERE Afdeling = ‘Watersport! 
AND Inkoper = '‘Najma Barends"; 


Het resultaat staat in Figuur 2-20. 


| Artikelnummer Is Artikelomschrijving Afdeling Inkoper 
101100 | Duikmasker, small, helder ___ Watersport Najma Barends 
101200 EK Ouikmasker, medium, helder Watersport Najma Barends 


Figuur 2-20 Resultaat samengestelde WHERE-clausule met AND 


We kunnen op een soortgelijke manier alle rijen in ARTIKEL vinden voor de afdelin- 
gen Camping of Klimmen door het volgende te schrijven: 


SELEEC Tas 
FROM ARTIKEL 
WHERE Afdeling = ‘Camping’ OR Afdeling = ‘Klimmen’; 


Het resultaat is Figuur 2-21. 


Artikelomschrijving Afdeling |___inkoper | 
Halvekoepeltent Charlotte Laan 
Camping 


Grondzeil halvekoepeltent Charlotte Laan 
Klimmen Johan Martens 


Lichtgewicht klimharnas 
Johan Martens 


Karabijnsluiting, ovaal 
Figuur 2-21 Resultaat samengestelde WHERE-clausule met OR 


Artikelnummer 
| 201000 
202000 
301000 
302000 


Het is ook mogelijk drie of meer OR- en AND-voorwaarden te combineren, maar het 
is in dergelijke gevallen makkelijker de operators IN en NOT IN te gebruiken. Stel 
dat we alle rijen in ARTIKEL willen vinden voor de inkopers Najma Barends, Char- 
lotte Laan en Johan Martens. We kunnen een WHERE-clausule met twee OR’s op- 
stellen, maar het is makkelijker het sleutelwoord IN als volgt te gebruiken: 


SEUEGT RS 

FROM ARTIKEL 

WHERE Inkoper IN ('Najma Barends', ‘Charlotte Laan', ‘Johan 
Martens’); 
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Indeze indeling wordt een reeks waarden tussen aanhalingstekens opgegeven. Een 


rij wordt geselecteerd als Inkoper gelijk is aan een van de geleverde waarden. Met 
Figuur 2-22 als resultaat. 


Artikelnummer Artikelomschrijving Afdeling Inkoper 
101100 Ouikmasker, small, helder | watersport Najma Barends 
101200 Duikmasker, medium, helder _ watersport Najma Barends 
Halvekoepeltent | Camping Charlotte Laan 

202000 Grondzeil halvekoepeltent |Camping__ ‚Charlotte Laan 
Lichtgewicht klimharnas emmen Johan Martens 
Karabijnsluiting, ovaal Klimmen Johan Martens 


Figuur 2-22 Resultaat Inkoper gelijk aan geleverde waarden 


We kunnen op een soortgelijke manier het volgende schrijven als we alle rijen in 


ARTIKEL willen vinden waarin de inkoper iemand anders is dan Najma Barends, 
Charlotte Laan of Johan Martens: 


SELECT * 
FROM ARTIKEL 


WHERE Inkoper NOT IN ('Najma Barends', 


‘Charlotte Laan’, 
‘Johan Martens’); 


Het resultaat is Figuur 2-23. 


Inkoper 
Peter Jansen 
Peter Jansen 


100100 Standaard SCUBA, geel 
100200 Standaard SCUBA, magenta Watersport 


Figuur 2-23 Resultaat Inkoper niet gelijk aan bepaalde waarden 


Artikelnummer Artikelomschrijving Afdeling 
Watersport 


Merk het volgende belangrijke verschil op tussen IN en NOT IN: een rij voldoet 
aan een IN-conditie als de kolom gelijk is aan een willekeurige waarde tussen de 


aanhalingstekens. Een rij voldoet echter aan een NOT IN-conditie als deze ongelijk 
is aan alle waarden tussen de aanhalingstekens. 


2.6.2 Bereik in WHERE-clausules 


Met het sleutelwoord BETWEEN kan voor een SQL-WHERE-clausule een bereik 
voor gegevenswaarden gespecificeerd worden. Het volgende SQL-statement: 


SELECT * 
FROM BESTELLING ITEM 
WHERE Totaalprijs BETWEEN 100 AND 200; 
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levert bijvoorbeeld het resultaat van Figuur 2-24. 


[ Bestellingnummer |_ Artikelnummer | Aantal | Stukprijs | Totaalprijs 
| 2000 101100 IE C 50,00 Ì € 200,00 
3000 101100 |_2 | €50,00 | €100,00 
| 2000 101200 NE € 100,00 
| 1000 [__202000 _ | 1 | €130,00 | €130,00 


Figuur 2-24 Resultaat samengestelde WHERE-clausule met BETWEEN 


Merk op dat de beide uitersten van het bereik, roo en 200, wel in de resulterende 
tabel zijn opgenomen. Het vorige SQL-statement is gelijkwaardig met: 


SELECT 
FROM BESTELLING ITEM 
WHERE Totaalprijs >= 100 AND Totaalprijs <= 200; 


Dit levert natuurlijk ook weer Figuur 2-24 op. 


2.6.3 Wildcards in WHERE-clausules 

Het sleutelwoord LIKE kan in WHERE-clausules worden gebruikt om kolomwaar- 
den te vinden, waarvan een deel wordt opgegeven. Stel dat we de rijen in de tabel AR- 
TIKEL willen vinden voor alle inkopers met de voornaam Pete. We vinden deze rijen 
door het sleutelwoord LIKE als volgt te gebruiken met de wildcard %: 


SELECT * 
FROM ARTIKEL 
WHERE Inkoper LIKE 'Pete%'; 


Het procentteken (%) is een wildcard (of joker) die een willekeurige reeks tekens re- 
presenteert. De string ‘Pete%’ geeft dus een willekeurige reeks tekens weer die met 
de letters Pete begint. Het resultaat van de bovenstaande query! zie je in Figuur 2-25. 


Artikelnummer Artikelomschrijving Afdeling |__inkoper | 
100100 Standaard SCUBA, geel Watersport 


100200 Standaard SCUBA, magenta Watersport 
Figuur 2-25 Resultaat samengestelde WHERE-clausule met LIKE 


Stel dat we de rijen in ARTIKEL willen vinden waarin het woord Tent ergens in de 
Artikelomschrijving voorkomt. Het woord Tent zou aan het begin, ergens in het mid- 


1 Mocht deze query in Access 2007 niet werken dan komt dat waarschijnlijk doordat Access niet is 
ingesteld op SQL-92, maar op SQL-89. Zie paragraaf 2.4.1. Deze oudere versie van SQL in Access 
gebruikt geen procentteken maar een sterretje * als wildcard voor een willekeurige reeks tekens 
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den of aan het eind van de beschrijving kunnen staan. We moeten daarom als volgt 
een jokerteken aan beide uiteinden van de LIKE-zinsnede gebruiken: 


SBEECT 
FROM ARTIKEL 
WHERE Artikelomschrijving LIKE '%Tent%'; 


Deze query zal alle rijen vinden waarin het woord Tent ergens in de Artikelomschrij- 
ving voorkomt. 


Het resultaat is Figuur 2-26. 


Artikelnummer 


201000 
202000 


Artikelomschrijving Afdeling | Inkoper 
Halvekoepeltent [camping | Charlotte Laan _ 
Grondzeil halvekoepeltent | Camping _ | Charlotte Laan 


Figuur 2-26 Resultaat samengestelde WHERE-clausule met LIKE ‘%TENT%’ 


We moeten soms ook op een specifieke plaats in de kolom naar een bepaalde waarde 
zoeken. Stel dat Artikelnummer-waarden zo zijn gecodeerd dat een 2 op de derde 
positie van rechts een bepaalde betekenis heeft — bijvoorbeeld dat het product een 
variant is van een ander product. Stel dat we om wat voor reden dan ook alle Artikel- 


nummers moeten vinden die een 2 bevatten op de derde positie van rechts. Stel nu 
dat we het volgende SQL-statement proberen: 


SELECT * 
FROM ARTIKEL 
WHERE Artikelnummer LIKE '%2%'; 


Dat is niet het gewenste resultaat. We hebben per ongeluk alle rijen opgehaald die 
een 2 bevatten op een willekeurige plaats in de waarde van Artikelnummer. Om het 
gewenste overzicht te maken, moeten we underscores ( _ ) gebruiken. Een onder- 
streepteken stelt een willekeurig teken voor. Het volgende SQL-statement zal alle 
rijen in ARTIKEL vinden met de waarde 2 in de derde positie van rechts: 


SELECT * 

FROM ARTIKEL 

WHERE Artikelnummer LIKE '%2_'; 
Merk op dat er twee underscores worden gebruikt: een voor de eerste positie van 


rechts en een tweede voor de tweede positie van rechts. Dat levert nu het gewenste 
resultaat als in Figuur 2-27. 


2 _InAccess 2007 met SQL-89 gebruik je een vraagteken als wildcard in plaats van een onderstreepteken. 
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[artikelnummer es p Artikelomschrijving Afdeling Inkoper 
_ 100200 | Standaard SCUBA, magenta _| Watersport Peter Jansen 
| 101200 | Duikmasker, medium, helder | watersport __ | Najma Barends 


Figuur 2-27 Resultaat samengestelde WHERE-clausule met LIKE ‘%2__” 


2.7 Berekeningen in SQL-query’s 


Het is mogelijk bepaalde soorten berekeningen uit te voeren in SQL-query's. Eén 
groep berekeningen betreft het gebruik van in SQL ingebouwde functies en een an- 
dere groep betreft eenvoudige rekenkundige bewerkingen op de kolommen in het 
SELECT-statement. We zullen hier deze beide bekijken. 


2.7.1 De in SQL ingebouwde functies 
SQL biedt vijf ingebouwde functies voor het uitvoeren van berekeningen op tabelko- 
lommen: SUM, AVG, MIN, MAX en COUNT. Sommige DBMS-producten bieden 
naast deze standaard ingebouwde functies nog een aantal extra functies. We richten 
ons hier alleen op de vijf standaardfuncties. 

Stel dat we de som van Bestellingtotaal willen weten voor alle bestellingen in BE- 
STELLING. We kunnen deze som als volgt opvragen: 


SELECT SUM(Bestellingtotaal) 
FROM BESTELLING; 


Het resultaat is te zien in Figuur 2-28. 


_monooo | 
L_€1.235,00 
Figuur 2-28 Resultaat met SUM 


Het resultaat van een SQL-statement is altijd een tabel. De tabel heeft in dit geval één 
rij en één kolom, en deze bevat de som van Bestellingtotaal. 

De som van Bestellingtotaal is geen kolom in een van de bestaande tabellen. 
De kolom heeft dus eigenlijk geen naam en Access levert daarom de tabel af met 
Exprrooo als defaultnaam voor de kolom. Als je meer van dergelijke kolommen in 
een tabel hebt, krijgt de volgende kolom de naam Exprroor, enzovoort. Andere DB- 
MS-producten zetten bijvoorbeeld ‘No column name! boven de kolom. 

Je kunt zelf een geschikte naam aan de kolom toekennen door het sleutelwoord 
AS te gebruiken: 


SELECT SUM(Bestellingtotaal) AS OrderSom 
FROM BESTELLING; 
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Het resultaat staat in Figuur 2-29. 


€ 1.235,00 


Figuur 2-29 Resultaat met SUM en AS 


Deze kolomnaam is veel zinvoller. Met het sleutelwoord AS is het mogelijk om elke 
willekeurige kolomnaam voor een kolom te kiezen. We zouden hier ook kunnen kie- 
zen voor Bestellingtotaal_Totaal, Totaalsom, enzovoort. 


Het gebruik van de ingebouwde functies kan interessanter zijn als je ze samen 
met een WHERE-clausule gebruikt. We kunnen bijvoorbeeld het volgende schrijven: 


SELECT SUM(Totaalprijs) AS Order3000Som 
FROM BESTELLING ITEM 
WHERE Bestellingnummer = 3000; 


Zie Figuur 2-31. 


Order3000Som 
€ 450,00 


Figuur 2-30 Resultaat ingebouwde functies met WHERE-clausule 


In een enkel statement kunnen meerdere ingebouwde functies worden gebruikt. We 
kunnen bijvoorbeeld het volgende schrijven: 


SELECT SUM(Totaalprijs) AS OrderltemSum, 
AVG(Totaalprijs) AS OrderltemAvg, 
MIN(Totaalprijs) AS OrderItemMin, 
MAX(Totaalprijs) AS OrderltemMax 

FROM BESTELLING ITEM; 


Het resultaat is te zien in Figuur 2-31. 


OrderltemSum OrderltemAvg OrderltemMin OrderltemMax 
€ 1.180,00 € 168,57 € 50,00 € 300,00 


Figuur 2-31 Resultaat meerdere ingebouwde functies 


De functie COUNT telt het aantal rijen. Het resultaat hiervan staat in Figuur 2-32. 


SELECT COUNT(*) AS AantalRijen 
FROM BESTELLING ITEM; 


Am 
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AantalRijen | 
| 
Figuur 2-32 Resultaat met COUNT 


Dit resultaat geeft aan dat de tabel zeven rijen heeft. Merk op dat we een asterisk 
moeten opgeven achter de functie COUNT als we rijen in een tabel willen tellen. 
COUNT kan worden gebruikt voor elk type gegevens, terwijl SUM, AVG, MIN en 
MAX alleen kunnen worden gebruikt voor numerieke gegevens. 

COUNT kan soms verrassende resultaten opleveren. Stel dat je het aantal afdelin- 
gen wilt tellen in de tabel ARTIKEL. Zou je het volgende schrijven: 


SELECT COUNT(Afdeling) AS AantalAfdelingen 
FROM ARTIKEL; 


dan krijgen we 8 als resultaat. Dat is het aantal rijen in de tabel ARTIKEL, in plaats 
van het aantal unieke waarden van Afdeling. Willen we de unieke waarden van Afde- 


ling tellen, dan moeten we het sleutelwoord DISTINCT als volgt gebruiken: 


SELECT COUNT(DISTINCT Afdeling) AS AantalAfdelingen 
FROM ARTIKEL; 


Je krijgt nu 3 als resultaat. 


Het is in Microsoft Access niet toegestaan het woord DISTINCT in een COUNT-uit- 
drukking te gebruiken. In plaats daarvan moet je een zogeheten subquery gebruiken: 


SELECT COUNT (*) AS AantalAfdelingen 
FROM (SELECT DISTINCT Afdeling FROM ARTIKEL) AS Afd; 


Meer over subquery's vind je in paragraaf 2.10. 


Het is behalve bij groepen (die we later definiëren) niet mogelijk de naam van een 
tabelkolom met een ingebouwde functie te combineren. Zouden we dit schrijven: 


SELECT Afdeling, COUNTC*) 
FROM ARTIKEL; 


dan krijgen we een foutmelding. Ingebouwde functies hebben nog een beperking 
die je moet kennen: je kunt ze niet in een WHERE-clausule gebruiken. Je kunt dus 
niet het volgende schrijven: 


SEBECT RS 


FROM BESTELLING 
WHERE Bestellingtotaal > AVG(Bestellingtotaal); 
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De poging een dergelijk statement te schrijven, zal ook weer in een foutmelding van 
het DBMS resulteren. In hoofdstuk 7 zie je hoe je het gewenste resultaat krijgt door 
een reeks SQL-views te gebruiken. 


2.7.2 Berekeningen in SELECT-statements 

Met SQL is het mogelijk berekeningen uit te voeren. Stel dat we de waarden van de 
totaalprijzen willen berekenen — misschien om te controleren of de gegevens in de 
tabel BESTELLING. ITEM kloppen. Je berekent de uitgebreide prijs als volgt: 


SELECT Aantal * Stukprijs AS TP 
FROM BESTELLING ITEM; 


Het resultaat zie je in Figuur 2-33. 


L_€300,00_| 
€ 300,00 
€ 100,00 


Figuur 2-33 Resultaat met SELECT en een berekening 


We kunnen het volgende schrijven als we deze berekende waarde willen vergelijken 
met de in Totaalprijs opgeslagen waarde, zie Figuur 2-34. 


SELECT Aantal * Stukprijs AS TP, Totaalprijs 
FROM BESTELLING ITEM; 


_1P__ [totaalprijs | 
€ 100,00 


Figuur 2-34 Resultaat berekening in vergelijking met de Totaalprijs 


Je kunt de beide waarden nu visueel met elkaar vergelijken om er zeker van te zijn 
dat de opgeslagen gegevens kloppen. 
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Het is in SQL ook mogelijk om strings te manipuleren. Stel dat we de kolommen 
Inkoper en Afdeling willen combineren tot een enkele kolom met de naam Sponsor. 
Het volgende statement zal het resultaat van Figuur 2-35 leveren: 


SELECT Inkoper + ‘in' + Afdeling AS Sponsor 
FROM ARTIKEL; 


Door het plusteken worden de naam van de inkoper, het woord in en de naam van de 
afdeling achter elkaar geplakt tot één lange string. 


Sponsor el 

Peter Jansen inWatersport | 
[Peter Jansen inWatersport 

Najma Barends inWatersport 

Najma Barends inWatersport 
Charlotte Laan ____inCamping 
Charlotte Laan inCamping 

Johan Martens inKlimmen 

Johan Martens inKlimmen 


Figuur 2-35 Resultaat manipulatie strings 


Het resultaat is niet fraai. Je kunt de extra spaties verwijderen door de functie RTRIM 
te gebruiken. De syntaxis van dergelijke functies kan van DBMS tot DBMS variëren. 
Zoek naar string functions als je meer over dit onderwerp wilt weten. 

Hier volgt een Microsoft Access- of SQL Server-statement dat de extra spaties aan 


het eind van Inkoper en Afdeling verwijdert: 


SELECT DISTINCT RTRIM(Inkoper) + ' in ' + RTRIM(Afdeling) AS 
Sponsor 
FROM ARTIKEL; 


Het resultaat is te zien in Figuur 2-36. Dat ziet er veel beter uit. Merk op dat er in het 
SQL-statement spaties staan om het woord in. 


Sponsor 
Charlotte Laan in Camping 


|Johan Martens in Klimmen 
Najma Barends in Watersport 
Peter Jansen in Watersport 


Figuur 2-36 Resultaat manipulatie strings zonder extra spaties 
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2.8 _Groeperen 


Rijen kun je in SQL groeperen op basis van gemeenschappelijke waarden door het 
sleutelwoord GROUP BY te gebruiken. Als je bijvoorbeeld GROUP BY Afdeling op- 
geeft in een SELECT-statement op de tabel ARTIKEL, dan zal het DBMS alle rijen 
eerst op Afdeling sorteren en alle rijen die dezelfde waarde bevatten daarna combi- 


neren tot een groep voor die afdeling. Er zullen zoveel groepen ontstaan als er unieke 
waarden zijn voor Afdeling. 


Dit SQL-statement: 


SELECT Afdeling, COUNT(*) AS AantalArtikelenPerAfdel ing 
FROM ARTIKEL 
GROUP BY Afdeling; 


zal het resultaat van Figuur 2-37 leveren: 


eri 
Watersport _|__ 4 | 


Figuur 2-37 Resultaat met GROUP BY Afdeling 


AantalArtikelenPerAfdeling 
2 


Het DBMS verkrijgt dat resultaat door de rijen eerst op Afdeling te sorteren en dan 
het aantal rijen te tellen dat dezelfde waarde heeft voor Afdeling. 
Een ander voorbeeld van het gebruik van GROUP BY is: 


SELECT Artikelnummer, AVG (Totaalprijs) AS GemiddeldeTP 
FROM BESTELLING ITEM 


GROUP BY Artikelnummer; 


Het resultaat daarvan is Figuur 2-38. 


Artikelnummer Gemiddelde 
100200 € 300,00 


Figuur 2-38 Resultaat met GROUP BY Artikelnummer 


De rijen zijn hier gesorteerd en gegroepeerd op Artikelnummer. De gemiddelde To- 
taalprijs is berekend voor elke groep Artikelnummer-items. 

Er kunnen meer kolommen worden opgenomen in een GROUP BY-expressie. 
Dit SQL-statement: 
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SELECT Afdeling, Inkoper, COUNT(*) AS 
AantalArtikelenPerAfdelingPerInkoper 
FROM ARTIKEL 


GROUP BY Afdeling, Inkoper; 


groepeert de rijen bijvoorbeeld eerst op de waarde van Afdeling en dan op die van 
Inkoper. Het statement telt daarna het aantal rijen voor elke combinatie van Afdeling 
en Inkoper. Het resultaat is te zien in Figuur 2-39. 


Afdeling Inkoper AantalArtikelenPerAfdelingPerinkoper 
Camping et Charlotte Laan 8 - 2 
Klimmen |Johan Martens | 2 
| Watersport | Najma Barends | 2 
Watersport |Peter Jansen Pe EK 2 | 


Figuur 2-39 Resultaat met GROUP BY Afdeling en Inkoper 


Je kunt natuurlijk ook WHERE- en ORDER BY-clausules gebruiken met SELECT- 
statements. Je ziet dat hier: 


SELECT Afdeling, COUNT(*) AS 
AantalArtikelenNiet30200PerAfdel ing 

FROM ARTIKEL 

WHERE Artikelnummer <> 302000 

GROUP BY Afdeling 

ORDER BY COUNT(*); 


Het resultaat staat in Figuur 2-40. 


Afdeling 
Klimmen 


Camping Ei 2 
Watersport | 4 


AantalArtikelenNiet30200PerAfdeling 


Figuur 2-40 WHERE-clausule met ORDER BY en SELECT 


Merk op dat een van de rijen van de afdeling Klimmen uit de telling is verwijderd, 
omdat deze niet aan de WHERE-voorwaarde voldeed. 

Plaats WHERE altijd voor GROUP BY omdat sommige DBMS-producten die 
volgorde vereisen. Het is dus veiliger om WHERE altijd voor GROUP BY te plaatsen. 

SQL biedt nog een toevoeging voor GROUP BY, dat de functionaliteit van GROUP 
BY verder uitbreidt: de operator HAVING. Met deze operator is het mogelijk om de 
groepen in het resultaat door middel van een conditie te beperken. 

We kunnen de vorige query hiermee zo aanpassen dat deze alleen groepen weer- 
geeft die meer dan een rij hebben door het volgende te schrijven: 


53 


13 


DEEL 1 | AAN DE SLAG 


SELECT Afdeling, COUNT(*) AS 
AantalArtikelenNiet30200PerAfdel ing 

FROM ARTIKEL 

WHERE Artikelnummer <> 302000 

GROUP BY Afdeling 

HAVING COUNT (*) > 1; 

ORDER BY Count(*); 


Het resultaat zie je in Figuur 2-41. 


AantalArtikelenNiet30200PerAfdeling | 
2 | 
4 | 


Figuur 2-41 Resultaat groepering met meer dan een rij 


Als je dit met het vorige resultaat vergelijkt, zie je dat de rij voor Klimmen (die een 
telling van 1 had) is verwijderd. 

Elk van de ingebouwde functies van SQL kan in de HAVING-clausule worden ge- 
bruikt. Het volgende is bijvoorbeeld geldige SQL: 


SELECT COUNT(*) AS Artikelnummer_Count, SUM(Stukprijs) 
AS TotalRev, Artikelnummer 

FROM BESTELLING ITEM 

GROUP BY Artikelnummer 

HAVING SUM(Stukprijs) = 100; 


Met als resultaat Figuur 2-42. 


Artikelnummer Count | TotalRev | Artikelnummer 
2 € 100,00 101100 
2 € 100,00 101200 


Figuur 2-42 Resultaat met HAVING-clausule 


Wees je ervan bewust dat een statement met zowel WHERE- als HAVING-clausu- 
les erg ingewikkeld kan zijn. De resultaten kunnen variëren, afhankelijk van of de 
WHERE-voorwaarde voor of na HAVING wordt toegepast. Hierbij wordt geadvi- 
seerd om WHERE altijd toe te passen vóór HAVING. 


2.9 Patronen zoeken in NASDAQ-beursgegevens 


Laten we een voorbeeld bekijken dat de kracht van de tot nu toe beschreven SQL de- 
monstreert, voordat we met SQL verdergaan. 

Stel, een vriendin vertelt je dat ze vermoedt dat de aandelenbeurs ertoe neigt 
op bepaalde dagen van de week te stijgen en op andere dagen te dalen. Ze vraagt je 


54 


INLEIDING IN STRUCTURED QUERY LANGUAGE (SQL) 


oude beursgegevens te bekijken om te bepalen of dat waar is. Ze wil specifiek in een 

indexfonds handelen dat de NASDAQ roo heet. Dat is een fonds van de honderd 

hoogst genoteerde bedrijven waarvan de aandelen op de NASDAQ-beurs worden 
verhandeld. Ze geeft je een tabel met gegevens van de afgelopen jaren over de NAS- 

DAQ roo ter analyse. Neem aan dat ze je deze gegevens geeft in de vorm van een 

tabel met de naam NDX in een relationele database. Je vindt deze tabel op de website 

bij dit boek: www.pearsoneducation.nl/kroenke. 

* Open Microsoft Access 2007. 

* Open de database NDX.accdb, hierin staan de NASDAQ-gegevens. 

* Klik op de Microsoft Office-knop. 

+ Klik onder in de rand van het venster op ‘Opties voor Access’. 

+ _ Klik op ‘Ontwerpfuncties voor objecten’. 

* Zorg ervoor dat er vinkjes staan onder ‘Met SQL Server compatibele syntaxis 
(ANSI 92)’: een vinkje bij: Deze database en een vinkje bij: Standaard voor nieu- 
we databases. 

Klik in het navigatievenster aan de linkerkant dubbel op de tabel NDX. 


Je ziet nu het bovenste deel van de tabel die uit 4611 rijen bestaat, zie Figuur 2-43. 
In plaats van dubbelklikken op de tabel NDX had je ook een query kunnen uitvoe- 
ren om alle kolommen van de tabel te zien: 


SELECT. + 
FROM NDX; 


2.9.1 De kenmerken van de gegevens bekijken 
In Figuur 2-43 zie je de eerste vijf rijen van tabel NDX. 


[2e EEE EE 
TClose _-‚ PriorClose «  ChangeClose -, Volume - TMonth - TDayofMonth -| TYear -, TDayofWee 
| 1520,46 1530,65 -10,1900000000001 24827600 January 9 2004 Friday 
| 1530,65 1514,26 16,3900000000001 26839500 January 8 2004 Thursday 
Ï 1514,26 1501,26 13 22942800 January 7 2004 Wednesday 
1501,26 1496,58 _4,63000000000006 22732200 January 6 2004 Tuesday 
1496,58 1463,57 33,01 23629100 January 5 2004 Monday 


Figuur 2-43 NDX-tabel 


De eerste kolom bevat de waarde van het fonds aan het einde van een handels- 
dag (TClose), de tweede kolom het fonds aan het einde van de vorige handelsdag 
(PriorClose). De derde kolom toont het verschil tussen het afsluitbedrag van de hui- 
dige dag en het afsluitbedrag van de vorige dag. Volume is het aantal verhandelde 
aandelen. De rest van de gegevens betreft de handelsdatum. 

Laten we eens kijken hoe de aandelenprijs verandert door de volgende query uit 
te voeren: 
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SELECT AVG (ChangeClose) AS GemiddeldeVeranderin 
MAX (ChangeClose) AS MaximaleWinst, 

MIN (ChangeClose) AS MaximaalVerlies 

FROM NDX; 


WW 


Het resultaat zie je in Figuur 2-44. 


GemiddeldeVerandering ‚ _MaximaleWinst MaximaalVerlies 
0,281167028199584 399,6 -401,03 


Figuur 2-44 Resultaat met NDX 


Opmerking 

DBMS-producten hebben veel functies voor het opmaken van de resultaten van een query. Het is mogelijk 
het aantal weergegeven decimale plaatsen te verminderen, valutatekens zoals S, £ of € weer te geven, 
punten of komma's weer te geven als decimaaltekens en de opmaak op andere manieren te veranderen. 
Deze functies zijn echter afhankelijk van het gebruikte DBMS. Zoek in de documentatie van het DBMS naaf 
de term opmaak of formatting om meer te weten te komen over dergelijke functies. 


Je besluit puur uit nieuwsgierigheid te kijken op welke dagen de maximale en mini- 
male veranderingen optraden. Je gebruikt een groter dan- en een kleiner dan-verge- 
lijking met nabijgelegen waarden, om te vermijden dat je de hele reeks decimalen 
moet invoeren die nodig is voor het uitvoeren van een is-gelijk-aanvergelijking: 


SELECT ChangeClose AS Verandering, TMonth AS Maand, 
TDayOfMonth AAS Dag, TYear AS Jaar 


FROM NDX 
WHERE ChangeClose >» 398 
OR ChangeClose < -400; 


Het resultaat staat in Figuur 2-45. 


Verandering ‚ Maand | Dag Jaar 
-401,03 Jenvary <3 | 1994 
IT a FER WES ES | 
399,6 January 3 | 2001 | 
Figuur 2-45 Resultaat met groter dan- en kleiner dan-vergelijking 


Dat is een verrassend resultaat! Zou er een of andere reden zijn waarom de grootste 
winst en het grootste verlies beide op 3 januari optraden? Je begint je af te vragen of 
er misschien iets in het idee van je vriendin zit. 


2.9.2 Naar patronen zoeken in de handel per dag van de week 
Je wilt weten of er een verschil is in de gemiddelde handel per dag van de week. Je 
schrijft daarom het volgende SQL-statement: 


__ TT 


INLEIDING IN STRUCTURED QUERY LANGUAGE (SqL) 


SELECT TDayOfWeek AS Dag, AVG (ChangeClose) AS 
GemiddeldeVerandering 
FROM NDX 


GROUP BY TDayOfWeek; 


Het resultaat staat in Figuur 2-46. 


Dag | GemiddeldeVerandering | 
| Friday |___0,146021739130452 
| Monday |___-1,03577929465299 H 
(rhursday | __217412972972975 | 
| Tuesday |__-0,711440677966085 
| Wednesday pl 0,777940552017005 _ J 


Figuur 2-46 Resultaat met TDayofweek 


Er lijkt inderdaad een verschil te zijn, afhankelijk van de dag van de week. De NAS- 
DAQ roo lijkt op maandag en dinsdag te dalen en op de andere drie dagen van de 
week omhoog te gaan. Vooral donderdag lijkt een goede dag te zijn om te verkopen. 
Maar je begint je af te vragen of dat patroon wel opgaat voor elk jaar. Je schrijft de 
volgende code om deze vraag te beantwoorden: 


SELEGT TDayOfWeek AS Dag, TYear AS Jaar, AVG (ChangeClose) 
AS GemiddeldeVerandering 
FROM NDX 


GROUP BY TDayOfWeek, TYear 
ORDER BY TDayOfWeek, TYear DESC; 


De gegevens beslaan twintig jaar en deze query resulteert dus in honderd rijen, waar- 
van je de eerste twaalf ziet in Figuur 2-47. 


— 


Dag Jaar GemiddeldeVerandering 
Friday 2004 -7,2700000000001 
Friday _ | 2003 -2,48499999999996 
Friday e 2002 -2,19419999999997 
Friday 2001 -19,5944 
[Friday BE 2000 8,8980392156863 
[Friday 1999 13,9656000000001 
Friday 1998 | 5,2640816326531 
Friday 1997 | __ -0,194799999999989 
Friday _[ 1996 0,819019607843153 
| Friday 0,691372549019617 
Friday 0,123725490196032 

i -0,899399999999989 


Figuur 2-47 Resultaat met TDayOfWeek en TYear 
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Je besluit het aantal rijen te beperken tot de laatste vijf jaar om de analyse te 


Ì vereenvoudigen: 
ú 
: SELECT TDayOfWeek AS Dag, TYear As Jaar, AVG (ChangeClose) 
AS GemiddeldeVerandering 
& FROM NDX 
je WHERE Tear > "1999 


GROUP BY TDayOfWeek, TYear 
Ì ORDER BY TDayOfweek, T 


Figuur 2-48 geeft een deel van het resultaat van deze query. 


‘__Dag ‘ Jaar GemiddeldeVerandering 
Friday 2004 -7,2700000000001 
Friday 2003 -2,484999955559I5 
Friday 2002 -2,194199399595597 
Friday 2001 -19,5944 
Friday 2000 8,8980392156863 
Monday | 2004 33,01 
Monday 2003 3,17416666666658 
Monday 2002 -2,60229166665664 
Monday . 2001 -3,17527033333333 

Monday 2000 -19,899574468035 
Thursday 2004 16,3900000000001 
Thursday « 2003 5,70700000000002 


En EA en 
Figuur 2-48 Resultaat met analyse van de laatste vijf jaar 


Het is jammer, maar de dag van de week lijkt geen goede indicatie te zijn voor winst 
of verlies — in elk geval niet voor dit fonds over deze tijdsperiode. 

We zouden deze casus kunnen voortzetten en de gegevens verder kunnen analy- 
seren, maar je zou ondertussen moeten begrijpen hoe nuttig SQL kan zijn voor het 


verwerken van een tabel. De SQL-oefenvragen aan het einde van dit hoofdstuk bevat- 
ten een aantal interessante casestudies. 


2.10 Query’s uitvoeren op twee of meer tabellen 


Tot nu toe werkten we in dit hoofdstuk steeds met slechts een tabel. We gaan nu ver- 
der met query’s op twee of meer tabellen. 

Stel dat je wilt weten hoeveel omzet de afdeling Watersport genereert. Je kunt de 
omzet berekenen als som van Totaalprijs, maar we hebben een probleem. Totaalprijs 
staat in de tabel BESTELLING. ITEM, terwijl Afdeling in de tabel ARTIKEL staat. We 
moeten dus gegevens uit twee tabellen verwerken. 

SQL biedt twee technieken voor het opvragen van gegevens uit meer tabellen: 
subquery’s en joins. Hoewel ze beide met meer tabellen werken, worden ze voor 
lichtelijk verschillende doeleinden gebruikt, zoals je hieronder zult zien. 


INLEIDING IN STRUCTURED QUERY LANGUAGE (SQL) 


2.10.1 Query’s uitvoeren op meer tabellen met subquery’s 

Hoe kunnen we nu de som van Totaalprijs opvragen voor alle artikelen van de afde- 

ling Watersport? We zouden een WHERE-clausule met het sleutelwoord IN kunnen 

gebruiken, als we de Artikelnummer-waarden van deze items maar zouden kennen. 
De Artikelnummer-waarden voor items in Watersport zijn 1oo1oo, 100200, 

Iorroo en ro1200 in de gegevens uit Figuur 2-4. Met deze waarden kunnen we de 

som van hun Totaalprijs opvragen met het volgende SQL-statement: 


SELECT SUM (Totaalprijs) AS OmzetWatersport 
F ROM BESTELLING ITEM 
WHERE _ Artikelnummer IN (100100, 100200, 101100, 101200); 


Het resultaat staat in Figuur 2-49. 


[ Omzetwatersport | 
€ 750,00 


Figuur 2-49 Som van Totaalprijs 


Meestal zul je de Artikelnummer-waarden die nodig zijn niet vooraf kennen. Er is 
echter wel een manier om deze waarden te verkrijgen: door SQL te gebruiken op de 
tabel ARTIKEL. Je kunt de Artikelnummer-waarden voor de afdeling Watersport op- 
vragen met: 


SELECT Artikelnummer 
FROM ARTIKEL 
WHERE Afdeling = '‘Watersport'; 


Dit SQL-statement geeft het resultaat van Figuur 2-50. 


Artikelnummer 


100100 


100200 
101100 
101200 


Figuur 2-50 Artikelnummers van Watersport 


Dat is de lijst van de gewenste Artikelnummer-waarden. 

We moeten de vorige twee SQL-statements nu alleen nog combineren om het ge- 
wenste resultaat te krijgen. Daartoe vervangen we de lijst van waarden in het eerste 
SQL-statement als volgt door het tweede SQL-statement: 
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SELECT SUM (Totaalprijs) AS OmzetWatersport 
FROM BESTELLING ITEM 
WHERE Artikelnummer IN 

(SELECT Artikelnummer 

FROM ARTIKEL 

WHERE Afdeling = ‘Watersport’ ); 


Dit levert opnieuw het resultaat van Figuur 2-49. 

Het tweede SELECT-statement, het statement tussen haakjes, noemen we een 
subquery. We kunnen drie of zelfs nog meer tabellen verwerken door meer sub- 
query’s te gebruiken. Neem bijvoorbeeld aan dat we de namen willen weten van de 
inkopers die gingen over de in januari 2009 verkochte producten. Merk om te be- 
ginnen op dat Inkoper in de tabel ARTIKEL staat en dat Maand en Jaar in de tabel 
BESTELLING staan. 


We kunnen de gewenste gegevens als volgt opvragen met een SQL-statement met 
twee subquery’s: 


SELECT Inkoper 
FROM ARTIKEL 
WHERE Artikelnummer IN 
(SELECT Artikelnummer 
FROM BESTELLING ITEM 
WHERE Bestellingnummer IN 
(SELECT Bestellingnummer 
FROM BESTELLING 


WHERE Maand = 'januari' AND Jaar = 2009)); 


Dit statement levert de tabel van Figuur 2-5r. 


{Peter Jansen 
NajmaBarends 


{Najma Barends __ \ 


Figuur 2-51 Inkopers in januari 2009 


Werk dit statement van onder naar boven door om te begrijpen hoe het werkt. 

+ Het onderste SELECT-statement haalt de lijst Bestellingnummers op van in 
januari 2009 verkochte bestellingen. 

+ Het middelste SELECT-statement haalt de Artikelnummer-waarden op van items 
in die bestellingen. 

+ Het bovenste SELECT-statement haalt ten slotte Inkoper op voor alle door het 
middelste SELECT-statement gevonden Artikelnummers. 


INLEIDING IN STRUCTURED QUERY LANGUAGE (SQL) 


Alle SQL die je eerder in dit hoofdstuk leerde kennen, kun je toepassen op een door 
een subquery geleverde tabel, ongeacht hoe ingewikkeld de SQL eruitziet. We kun- 
nen bijvoorbeeld dubbele rijen verwijderen door DISTINCT op het resultaat toe te 
passen. Of we kunnen als volgt gebruikmaken van GROUP BY en ORDER BY: 


SELECT Inkoper, COUNT (*) AS Aantal Verkocht 
FROM ARTIKEL 
WHERE Artikelnummer IN 


(SELECT Artikelnummer 

FROM BESTELLING ITEM 

WHERE Bestellingnummer IN 

(SELECT Bestellingnummer 

FROM BESTELLING 

WHERE Maand = ‘januari! AND Jaar = 2009)) 
GROUP BY Inkoper 
ORDER BY COUNT(*)DESC; 


Het resultaat is te zien in Figuur 2-52. 


Inkoper | Aantalverkocht 
Najma Barends MIE 7 
Peter Jansen | 1 


Figuur 2-52 Resultaat met meerdere subquery’s 


Subquery’s zijn weliswaar zeer krachtig, maar ze hebben een zwaarwegende beper- 
king. De geselecteerde gegevens kunnen alleen uit de tabel op het hoogste niveau 
komen. We kunnen een subquery niet gebruiken om gegevens op te vragen die uit 
meer dan een tabel afkomstig zijn. We moeten daarvoor een join gebruiken. 


2.10.2 Query’s uitvoeren op meer tabellen met joins 

De SQL join-operator wordt gebruikt om twee of meer tabellen te combineren door 
de rijen van de ene tabel achter de rijen van een andere tabel op te nemen. Kijk bij- 
voorbeeld eens naar de beide tabellen in Figuur 2-53. De tabel STUDENT heeft drie 
kolommen over studenten. De tabel RESULTAAT heeft drie kolommen over de cij- 
fers die de studenten behaalden in een klas. 


We kunnen de rijen van de ene tabel samenvoegen met de rijen van de andere tabel 
met het volgende SQL-statement: 


SEMECT ER 
FROM STUDENT, RESULTAAT; 


Dit statement plakt alle rijen van de ene tabel domweg achter de rijen van de tweede 
tabel. Het resultaat is te zien in Figuur 2-54. 
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ene 
i 100 | _97 |Exament | 
Ì 200 |_85 _|Examen1 | 
! 300 |__90 \Examen1 | 
100 |__81 _|Examen2 | 
Î 200 |_75 |examen2 | 
| 300 |_72 \Examen2 | 


STUDENT 
Studentnummer 


Studentnaam | JaarVaninschrijving 
100 _ | Cauchy | 2010 
200 | 


| Gauss 2011 


300 | Hilbert 


2012 


| 


Figuur 2-53 Voorbeeldgegevens voor STUDENT en RESULTAAT 


STUDENT. 


| 


Studentnummer jistudentnaam JaarVaninschrijving ores Punten | Examen 
| 100 | Cauchy 2010 100 97 __ |Examen1 , 
| 200 | Gauss | 2011 100 97 _|Examen1 | 
300 Hilbert 2012 100 97 __ [examen 
100 | Cauchy 2010 | 200 85 [examen | 
200 | Gauss 2011 il 200 85 _ |Examen1 
300 | Hilbert 2012 200 85 _ |exament | 
100 Cauchy 2010 300 90 _ | Examen 1 
200 | Gauss 2011 300 90 _ |examen1 
300 nn jure) 300 oo [exament | 
100 Cauchy 2010 100 81 |examen2 | 
100 81 |Examen2 | 
100 81 Examen 2 
200 75 _ |Examen2 
200 75 |Examen2 | 
Hilbert 200 75 _|Examen2 | 
300 72 \examen2 | 
300 72 [examen2 | 
Hilbert 300 72 Examen 2 | 


Figuur 2-54 Resultaat samenvoeging van rijen uit verschillende tabellen 


Deze tabel heeft achttien rijen, omdat er drie rijen studenten en zes rijen examens 
zijn: 3 * 6 =18. Merk op dat elk van de studenten Cauchy, Gauss en Hilbert met elk 
van de zes rijen van RESULTAAT is gecombineerd. 

Zou je een van deze studenten zijn, dan zou je bezwaar hebben tegen deze ta- 
bel. Je zou niet alleen met jouw eigen resultaten in verband zijn gebracht, maar 
ook met de resultaten van twee andere studenten. We moeten echter alleen de rij- 
en selecteren waarvoor het Studentnummer van STUDENT overeenkomt met het 
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Studentnummer in RESULTAAT. We kunnen dat makkelijk doen door simpelweg 
een WHERE-clausule toe te passen in het SQL-statement: 
SEKEGTe 
FROM STUDENT, RESULTAAT 


WHERE STUDENT .Studentnummer — RESULTAAT.Studentnummer:; 


Het resultaat is te zien in Figuur 2-55. 


SIUDEND, Studentnaam L JaarVaninschrijving | Pl Punten | Examen | 

| Studentnummer Ë Studentnummer | 
100 Cauchy 2010 100 |_ 97 _|Examen1 
200 | Gauss 2011 200 |_85 _|examen1 
__300 Hilbert | 2012 300 90 | Examen 1 
100 | Cauchy NE 100 | 81 _ [examen 2 
200 [Gauss 2011 in 200 75 [Examen 2 
300 | Hilbert RET [een A00 |_72 [examen 2 


Figuur 2-55 Resultaat samenvoeging van rijen uit verschillende tabellen met WHERE-clausule 


Vergelijk dit resultaat met de gegevens uit Figuur 2-54 en je ziet dat alleen de juiste 
cijfers in verband zijn gebracht met elke student. Je kunt dit ook zien aan het feit dat 
de waarde van Studentnummer van STUDENT (de eerste kolom) in elke rij identiek 
is aan de waarde van Studentnummer van RESULTAAT (de op een na laatste kolom). 
Dat was bij de eerdere resultaten niet het geval. 


Opmerking 

De syntaxis STUDENT.Studentnummer betekent het Studentnummer uit de tabel STUDENT. 
RESULTAAT.Studentnummer verwijst op een soortgelijke manier naar het Studentnummer in de tabel 
RESULTAAT. Je kunt een kolomnaam altijd op deze manier kwalificeren met de naam van de bijbehorende 
tabel. Dit is met name nodig als er twee tabellen zijn die gelijknamige kolommen bevatten. We hebben 
dit tot dusver nog niet gedaan omdat we telkens maar met een tabel hebben gewerkt. De eerder 
gebruikte SQL zou echter net zo goed werken met een syntaxis zoals ARTIKEL.Inkoper (in plaats van alleen 
Inkoper) of BESTELLING ITEM.Stukprijs (in plaats van alleen Stukprijs). 


De tabel die ontstaat door twee tabellen samen te voegen, noemen we een join. De 
join die ontstaat als de tabellen worden gecombineerd via een is-gelijk-aan-voorwaar- 
de (zoals die voor Studentnummer) noemen we een equijoin. Als mensen join zeg- 
gen bedoelen ze in de meeste gevallen equijoin. Dit type join wordt ook wel inner 
join genoemd. 

We kunnen een join gebruiken om gegevens uit twee of meer tabellen te combi- 
neren. Stel bijvoorbeeld dat we de naam van de Inkoper en de Totaalprijs willen la- 
ten zien voor alle verkochte items die deze Inkoper beheert. De volgende SQL levert 
dat resultaat: 


63 


ee 
en UN 


DEEL 1} AAN DE SLAG 


SELECT Inkoper. Totaalprijs 
FROM ARTIKEL, BESTELLING ITEM 
WHERE ARTIKEL.Artikelnummer = BESTELLING ITEM.Artikelnummer; 


Als we de gegevens uit Figuur 2-4 gebruiken, is het resultaat dat van Figuur 2-56. 


Í Inkoper \_ Totaalprijs | 
! Peter Jansen |__€ 300,00 
\NajmaBarends __ | €200,00 | 
‘Najma Barends ‚_ € 100,00 
\Najma Barends _ | €100,00 
\Najma Barends _ | €50,00 
| Charlotte Laan |__€ 300,00 
Charlotte Laan \_€ 130,00 


Figuur 2-56 Resultaat equijoin 


Nogmaals: het resultaat van een SQL-statement is altijd een enkele tabel. Op dat re- 
sultaat kunnen we dus alle SQL toepassen die we tot dusver hebben leren kennen 


voor het werken met een enkele tabel. We kunnen bijvoorbeeld als volgt gebruikma- 
ken van GROUP BY en ORDER BY: 


SELECT Inkoper, SUM(Totaalprijs) AS Omzetinkoper 
FROM ARTIKEL, BESTELLING ITEM 


WHERE ARTIKEL. Artikelnummer = BESTELLING ITEM.Artikelnummer 
GROUP BY Inkoper 


ORDER BY SUM(Totaalprijs)DESC; 


Het resultaat is dat van Figuur 2-57. 


\Inkoper |_Omzetinkoper | 
\NajmaBarends | _ €450,00 | 
\Charlottetaan | €430,00 | 
Peter Jansen | € 300,00 


Figuur 2-57 Resultaat met GROUP BY en ORDER BY 


We kunnen deze syntaxis uitbreiden om drie of meer tabellen te combineren. Stel 
dat we de Inkoper en de Totaalprijs en Maand willen zien voor alle door elke inkoper 


beheerde waren. We moeten alle drie de tabellen als volgt samenvoegen om deze ge- 
gevens te krijgen: 


SELECT Inkoper, Totaalprijs, Maand 

FROM ARTIKEL, BESTELLING ITEM, BESTELLING 

WHERE ARTIKEL.Artikelnummer = BESTELLING ITEM.Artikelnummer 
AND BESTELLING ITEM.Bestellingnummer BESTELLING. 
Bestel lingnummer ; 


INLEIDING IN STRUCTURED QUERY LANGUAGE (SQL) 


Het resultaat is te zien in Figuur 2-58. 


[Inkoper [totaalprijs | Maand 
[peter Jansen |__€300,00 | januari | 
| Najma Barends €200,00 [december 
Najma Barends € 100,00 | januari 
Najma Barends 5 € 100,00 {december 
| Najma Barends | € 50,00 | januari 
Charlotte Laan — |_€ 300,00 [december 
Charlotte Laan |__€130,00 | december 


Figuur 2-58 Resultaat samenvoeging Inkoper, Totaalprijs en Maand 


We kunnen het resultaat nog verbeteren door ORDER BY te gebruiken en de resul- 
taten misschien ook nog te groeperen. 
Meer detailinformatie over joins is te lezen in hoofdstuk 7. 


Samenvatting 


Er zijn twee soorten SQL-statements: DML- en DDL-statements. DML-statements 
bevatten statements voor het uitvoeren van query’s en voor het invoegen, bijwerken 
en verwijderen van gegevens. Dit hoofdstuk gaat alleen in op DML-querystatements. 

SQL is door IBM ontwikkeld en ANSI-standaard SQL-g2 is de meest gebruikte. 
SQL is een subtaal die je in andere programmeertalen kunt opnemen, of direct aan 
het DBMS kunt doorgeven. Het kennen van SQL is van onmisbaar belang voor ken- 
niswerkers, applicatieprogrammeurs en databasebeheerders. 

Alle DBMS-producten verwerken SQL. Microsoft Access verbergt SQL, maar 
SQL Server, Oracle, DB2 en MySQL vereisen dat je SQL gebruikt. 

Vrijwel alle voorbeelden in dit hoofdstuk zijn gebaseerd op drie tabellen die zijn 
geëxtraheerd uit de werkdatabase van Swaen Buitensport. Dergelijke uittreksels uit 
databases worden veel gebruikt en zijn belangrijk. Figuur 2-4 toont voorbeeldgege- 
vens voor deze drie tabellen. 

De basisvorm van een SQL-querystatement is SELECI/FROM/WHERE. De te 
selecteren kolommen worden opgegeven na SELECT. De te verwerken tabel(len) 
worden opgegeven na FROM. Alle eventuele beperkingen die we aan de gegevens- 
waarden moeten opleggen, worden opgegeven na WHERE. Tekst- en datumgege- 
vens moeten tussen enkele aanhalingstekens worden gezet in een WHERE-clausule. 
Numerieke gegevens hoeven niet tussen aanhalingstekens te staan. Dit hoofdstuk 
beschrijft hoe je SQL-statements rechtstreeks aan Microsoft Access 2007 doorgeeft. 

Het gebruik van de volgende sleutelwoorden en symbolen werd uitgelegd in dit 
hoofdstuk: ORDER BY, DESC, ASC, AND, OR, IN, NOT IN, BETWEEN, LIKE, %, 
— *, SUM, AVG, MIN, MAX, COUNT, AS, GROUP BY en HAVING. Je moet weten 
hoe je deze mogelijkheden door elkaar gebruikt om de gewenste resultaten te krij- 
gen. WHERE wordt standaard toegepast vóór HAVING. 

Je kunt query’s uitvoeren op meer tabellen tegelijk door subquery’s en joins te ge- 
bruiken. Subquery’s zijn geneste query’s die gebruikmaken van de sleutelwoorden 
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INen NOT IN. Een SQL-subquery wordt tussen haakjes gezet. Je kunt met een sub- 
query alleen gegevens weergeven uit de bovenste tabel in de geneste query. Je maakt 
een join door meer tabelnamen op te geven in de FROM-clausule. Een WHERE- 
clausule gebruik je om een equijoin te krijgen. Joins kunnen gegevens uit meerdere 
tabellen weergeven. Je maakt in hoofdstuk 8 kennis met een ander soort subquery, 
waarmee je dingen kunt die je niet met joins kunt. 


Belangrijke termen 


ad-hoc-query’s ISO 
AND join 
ANSI JOIN … ON 
AS LIKE 
AVG MAX 
BETWEEN MIN 
COUNT NOT IN 
DDL OR 
DESC ORDER BY 
DISTINCT QBE 
DML SELECT 
equijoin SELECT/FROM/WHERE 
FROM Structured Query Language (SQL) 
GROUP BY subquery 
HAVING SUM 
IN XML 
inner join 
Oefeningen 
1. Waar is SQL de afkorting van? 
2. Waar is DML de afkorting van? Wat zijn DML-statements? 
3. _Waaris DDL de afkorting van? Wat zijn DDL-statements? 
4. Vat de achtergrond van SQL samen. 
5. 
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Wat is SQL-92? Hoe staat dat in verband met de SQL-statements uit dit 
hoofdstuk? 


Waarom wordt SQL beschreven als een datasubtaal? 
Beschrijf drie manieren waarop SQL kan worden gebruikt. 
Leg uit op welke manier Microsoft Access gebruikmaakt van SQL. 


Leg uit op welke manier DBMS-producten voor grote bedrijven gebruikmaken 
van SQL. 


„ Vat samen hoe de gegevens werden gewijzigd en gefilterd tijdens het maken van 


het gegevensuittreksel voor Swaen Buitensport. 


Leg in algemene termen uit wat de relaties zijn tussen de tabellen BESTEL 
LING, BESTELLING. ITEM en ARTIKEL. 


INLEIDING IN STRUCTURED QUERY LANGUAGE (SQL) 


De database van Swaen Buitensport bevat ook nog de tabellen VOORRAAD en WIN- 
KELVESTIGING. De schema's voor deze tabellen, samen met de tabel ARTIKEL, 
zien er als volgt uit: 


ARTIKEL (Artikelnummer, Artikelomschrijving, Winkel, Inkoper) 
VOORRAAD (Artikelnummer, Winkelvestiging, 
Artikelomschrijving, AantalOpVoorraad, AantalInBestelling) 
WINKEL (Winkelvestiging, Manager, VierkanteMeter) 


Je kunt de database van Swaen Buitensport met alle tabellen en gegevens downloa- 
den van de website www.pearsoneducation.nl/kroenke. 


12. Het ontwerp van de tabel VOORRAAD bevat een opzettelijke fout. Deze fout is 
expres gemaakt om ervoor te zorgen dat je een aantal van de volgende vragen 
kunt beantwoorden door alleen gebruik te maken van de tabel VOORRAAD. 
Vergelijk de tabellen ARTIKEL en VOORRAAD en ga na wat de ontwerpfout is 
die we maakten. Waarom zouden we hem gemaakt hebben? 


Gebruik voor de vragen 13 tot en met 40 uitsluitend de tabel VOORRAAD. 


13. Schrijf een SQL-statement voor het weergeven van Artikelnummer en 
Artikelomschrijving. 

14. Schrijf een SQL-statement voor het weergeven van Artikelomschrijving en 
Artikelnummer. 

15. Schrijf een SQL-statement voor het weergeven van Winkelvestiging. 

16. Schrijf een SQL-statement voor het weergeven van Winkelvestiging, zonder ge- 
dupliceerde gegevens. 

17. Schrijf een SQL-statement voor het weergeven van alle kolommen, zonder * te 
gebruiken. 

18. Schrijf een SQL-statement voor het weergeven van alle kolommen en maak 
daarbij gebruik van *. 

ig. Schrijf een SQL-statement voor het weergeven van alle gegevens over producten 
met een AantalOpVoorraad dat groter is dan nul. 

20. Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van de producten waarvan AantalOpVoorraad gelijk is aan nul. 

21. Schrijf een SQL-statement voor het weergeven van Artikelnummer, Artikel- 
omschrijving en Winkelvestiging voor producten waarvan AantalOpVoorraad 
gelijk is aan nul. Sorteer het resultaat in oplopende volgorde op Winkelvestiging. 

22. Schrijf een SQL-statement voor het weergeven van Artikelnummer, Artikel- 
omschrijving en Winkelvestiging voor producten waarvan AantalOpVoorraad 
gelijk is aan nul. Sorteer het resultaat in aflopende volgorde op Winkelvestiging 
en in oplopende volgorde op Artikel. 
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23. 


24. 


25. 


26. 


27. 


28. 


29. 


31. 


ND 


3 


33. 


had 


34. 
35. 


36. 


37- 
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Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel 
omschrijving van alle producten waarvan AantalOpVoorraad gelijk is aan nul en 
AantalInBestelling groter is dan nul. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle producten waarvan AantalOp Voorraad gelijk is aan nul, of 
AantalInBestelling gelijk is aan nul. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle items die zijn opgeslagen in de winkels in Seattle, Chica- 
go en New Jersey. Maak geen gebruik van IN. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle items die zijn opgeslagen in de winkels in Seattle, Chica- 
go en New Jersey. Maak gebruik van IN. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle items die niet zijn opgeslagen in de winkels in Seattle 
Chicago of New Jersey. Maak geen gebruik van NOT IN. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle items die niet zijn opgeslagen in de winkels in Seattle, 
Chicago of New Jersey. Maak gebruik van NOT IN. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer, Artikel- 
omschrijving en AantalOpVoorraad van alle producten waarvan AantalOp Voor- 
raad groter is dan 1 en kleiner is dan 1o. Gebruik BETWEEN. 


. Schrijf een SQL-statement voor het weergeven van Artikelnummer en 


Artikelomschrijving van alle producten waarvan de beschrijving begint met 
‘Halvekoepel’. 

Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle producten waarbij ‘koepel’ in de beschrijving voorkomt. 
Schrijf een SQL-statement voor het weergeven van Artikelnummer en Winkel- 
vestiging voor alle producten waarbij de derde letter van links in Winkelvesti- 
ging een ‘w' is. 

Schrijf een SQL-expressie die alle ingebouwde functies gebruikt op de kolom 
AantalOpVoorraad. Neem zinvolle kolomnamen op in het resultaat. 

Leg uit wat het verschil is tussen COUNT en SUM. 

Schrijf een SQL-expressie die een enkele kolom met de naam ItemLocatie pro- 
duceert en die Artikelomschrijving, de zinsnede ‘is op voorraad in’ en Winkel- 
vestiging met elkaar combineert voor alle producten waarvan AantalOpVoorraad 
groter is dan nul. Doe geen moeite voor het verwijderen van eventuele spaties 
aan het einde. 

Schrijf een SQL-expressie voor het weergeven van Winkelvestiging en een op- 
telling van AantalOpVoorraad, gegroepeerd op Winkelvestiging. Noem de op- 
telling TotaalAantalltemsOpVoorraad en geef het resultaat weer in aflopende 
volgorde van TotaalAantalltemsOpVoorraad. 

Schrijf een SQL-expressie voor het weergeven van Winkelvestiging en een 
optelling van AantalOpVoorraad, gegroepeerd op Winkelvestiging. Laat 
alle items weg waarvoor de optelling groter is dan 2. Noem de optelling 


38. 


39. 


40. 
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TotaalAantalltemsOpVoorraad en geef het resultaat weer in aflopende volgorde 
van TotaalAantalltemsOpVoorraad. 

Schrijf een SQL-expressie voor het weergeven van Winkelvestiging en een op- 
telling van AantalOpVoorraad, gegroepeerd op Winkelvestiging. Laat alle items 
weg waarvoor de optelling groter is dan 2. Laat alleen groepen zien met optellin- 
gen voor minder dan twee items. Noem de optelling TotalltemsOnHand en geef 
het resultaat weer in aflopende volgorde van TotalltemsOnHand. 

Wat werd in je antwoord op vraag 38 het eerst toegepast: WHERE of HAVING? 
Waarom? 

Schrijf een SQL-expressie voor het weergeven van Winkelvestiging, de som van 
AantalInBestelling en de som van AantalOp Voorraad, gegroepeerd op Winkelves- 
tiging en op AantallnBestelling. Laat alle items weg waarvoor de optelling groter 
is dan 2. Noem de optelling van AantalInBestelling TotaalAantalltemsInBestel- 
ling en noem de optelling van AantalOp Voorraad TotaalAantalltemsOp Voorraad. 


Gebruik de tabellen VOORRAAD en WINKEL voor het beantwoorden van vraag 41 
tot en met 47. 


41. 


42. 


43. 


44. 


45. 


46. 
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Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle items die zijn opgeslagen in een winkel die wordt beheerd 
door ‘Smith’. Gebruik een subquery. 

Schrijf een SQL-statement voor het weergeven van Artikelnummer en Artikel- 
omschrijving van alle items die zijn opgeslagen in een winkel die wordt beheerd 
door ‘Smith’. Gebruik een join. 

Schrijf een SQL-statement voor het weergeven van Winkelvestiging en het ge- 
middelde van AantalOpVoorraad voor alle items die zijn opgeslagen in een win- 
kel die wordt beheerd door ‘Smith’. Gebruik een subquery. 

Schrijf een SQL-statement voor het weergeven van Winkelvestiging en het ge- 
middelde van AantalOpVoorraad voor alle items die zijn opgeslagen in een wa- 
renhuis dat wordt beheerd door ‘Smith’. Gebruik een join. 

Schrijf een SQL-statement voor het weergeven van Winkelvestiging, Mana- 
ger en AantalOp Voorraad voor alle items die zijn opgeslagen in een winkel die 
wordt beheerd door ‘Smith’. Gebruik een join. 

Leg uit waarom je geen subquery kunt gebruiken in het antwoord op vraag 45. 

Leg uit waarin subquery's en joins van elkaar verschillen. 


Projectvragen 


De volgende vragen gaan over de database NDX uit paragraaf 2.9. Je kunt een kopie 
van deze database downloaden van www.pearsoneducation.nl/kroenke. 


48. 


Schrijf SQL-query’s om de volgende resultaten te produceren: 
a. De ChangeClose op vrijdagen. 
b. De minimale, maximale en gemiddelde ChangeClose op vrijdagen. 
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q 


h. 


De gemiddelde ChangeClose, gegroepeerd op TYear. Geef TYear weer. 
De gemiddelde ChangeClose, gegroepeerd op TYear en TMonth. Geef 
TYear en TMonth weer. 
De gemiddelde ChangeClose, gegroepeerd op TYear, TQuarter en TMonth, 
weergegeven in aflopende volgorde van het gemiddelde (je zult het gemid- 
delde een naam moeten geven om daarop te kunnen sorteren). Geef TYear, 
TQuarter en TMonth weer. Merk op dat maanden in alfabetische volgorde 
worden weergegeven, in plaats van in kalendervolgorde. Leg uit wat je moet 
doen om de maanden in kalendervolgorde te kunnen weergeven. 
Het verschil tussen de maximale ChangeClose en de minimale Change- 
Close, gegroepeerd op TYear, TQuarter en TMonth, weergegeven in af- 
lopende volgorde van het verschil (je zult het verschil een naam moeten 
geven om daarop te kunnen sorteren). Geef TYear, TQuarter en TMonth 
weer. 
De gemiddelde ChangeClose, gegroepeerd op TYear, weergegeven in af- 
lopende volgorde van het gemiddelde (je zult het gemiddelde een naam 
moeten geven om daarop te kunnen sorteren). Geef alleen groepen weer 
waarvoor het gemiddelde positief is. 
Geef een enkel veld weer met de datum, in de vorm dag/maand/jaar. Maak 
je niet druk over achtergevoegde spaties. 


49. Is het mogelijk dat het volume (het aantal verhandelde aandelen) op de een of 
andere manier in verband staat met de richting van de aandelenmarkt? Gebruik 
de SQL die je in dit hoofdstuk leerde om deze mogelijkheid te onderzoeken. Ge- 
bruik minstens vijf verschillende SQL-statements in je onderzoek. 


Marcia’s Chemische Reiniging 


Marcia's Chemische Reiniging is een goedlopende stomerij in een hoofdstad met 
welgestelde inwoners. Marcia zorgt ervoor dat haar zaak boven haar concurrenten 
uitsteekt door een betere service te bieden. Ze wil al haar klanten en hun orders bij- 
houden. Ze is van plan haar klanten via e-mail te laten weten dat hun kleding klaar 


is. Ze heeft een eerste database met een aantal tabellen ontwikkeld om deze dienst- 
verlening te kunnen bieden. Drie van deze tabellen zijn: 


CUSTOMER (CustomerID, FirstName, LastName, Phone, E-mail) 
INVOICE (InvoiceNumber, CustomerNumber, Dateln, DateOut, 
Total Amount) 

INVOICE ITEM (ZnvoiceNumber, ItemNumber, Item, Quantity, 
UnitPrice) 


We raden je aan om in Access 2007 een database te maken met de naam H2Marcia- 
CR.accdb en deze te voorzien van de drie genoemde tabellen. In de figuren hieron- 
der vind je de eigenschappen en gegevens voor de verschillende tabellen. 
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CUSTOMER 
veldnaam | Gegevenstype Sleutel 


Opmerkingen 


Vereist 


| customerlD | Numeriek | Primaire sleutel [Ja Long Integer 
FirstName | Tekst(25) [Nee ja 

| LastName Tekst(25) [Nee |ja 

! Phone Tekst(12) | Nee | Nee Is 

|E-mail [rekst(100) ___ Înee [Nee gi 


Figuur 2-59 Kolom kenmerken voor de CUSTOMER-tabel 


INVOICE 
Veldnaam | Gegevenstype Sleutel Vereist Opmerkingen 
InvoiceNumber | Numeriek Primaire sleutel Long Integer 
CustomerNumber | Numeriek Vreemde sleutel Long Integer 
Dateln | Datum/tijd [Nee Nee 
DateOut pe | Datum/tijd [nee Nee 
TotalAmount | valuta [Nee Ja Automatisch | 


Figuur 2-60 Kolom kenmerken voor de INVOICE-tabel 


INVOICE_ITEM 
Veldnaam [_ Gegevenstype Sleutel Vereist Opmerkingen 
InvoiceNumber Numeriek Primaire sleutel, Long Integer 
D _ Vreemde sleutel 

ItemNumber Numeriek [primaire sleutel Long Integer 

term | Tekst Nee 

Quantity | Numeriek Nee Long Integer 
| UnitPrice | Valuta Nee Automatisch | 


Figuur 2-61 Kolom kenmerken voor de INVOICE_ITEM-tabel 


Gegevens voor de drie tabellen: 


CUSTOMER 


CustomerlD FirstName | LastName 


1 Nikki Kaccaton 723-543-1233 | Nkaccaton@somewhere.com 

2 Brenda Catnazaro 723-543-2344 |[Bcatnazaro@somewhere.com 

3 Jeme 723-543-3455 

len 

5___[oeorge [mile 
E 6 Kathy 723-514-9877 | Kmiller@somewhere.com 


723-512-8766 | Bmiller@somewhere.com 


Figuur 2-62 Voorbeeldgegevens CUSTOMER 
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JE [invoiceumber | CustomerNumber [_ Datein | pateout | rotalAmount 
Â 2009001 6-10-2011 € 158,50 
4-10-2011 | 6-10-2011 € 25,00 

6-10-2011 | 8-10-2011 € 55,00 


2009004 
2009005 
2009006 
2009007 
2009008 


2009009 


Figuur 2-63 Voorbeeldgegevens INVOICE 


11-10-2011 | 13-10-2011 € 152,50 


11-10-2011 13-10-2011 € 7,00 
12-10-2011 14-10-2011 € 140,50 


12-10-2011 14-10-2011 € 27,00 


6-10-2011 [ 8-10-2011 € 17,50 
7-10-2011 ee € 12,00 


uiglwlwinjel= [Nn 


INVOICE_ITEM 
[invoiceNumber [ itemNumber |__ item | quantity | unitprice 
1 Blouse 2 € 3,50 
2009001 2 Dress Shirt 5 € 2,50 
3 Formal Gown | 2 __| €10,00 
RE osdorl 4 | Slacks-Mens | 10 € 5,00 
2009001 5 Slacks-Womens 10 € 6,00 
2009001 6 Suit-Mens 1 € 9,00 
1 Dress Shirt |_10 € 2,50 
1 Slacks-Mens 5 € 5,00 
2009003 2 Slacks-Womens 4 € 6,00 
1 Dress Shirt 7 € 2,50 
1 Blouse 2 € 3,50 
2009005 2 Dress Shirt 2 €2,50 | 
2009006 1 Blouse 5 1450 
2009006 2 Dress Shirt 10 | €2,50 
3 Slacks-Mens 10 € 5,00 
4 | Slacks-Womens 10 € 6,00 
2009007 1 Blouse 2 € 3,50 
2009008 Blouse 3 € 3,50 
Slacks-Mens 8 € 5,00 
[_2009008 | 4 | slacks-Womens 10 € 6,00 
suit-Mens € 9,00 


Figuur 2-64 Voorbeeldgegevens INVOICE ITEM 


Schrijf SQL-statements die de volgende informatie produceren: 


A. Geef alle gegevens uit alle tabellen weer. 

B. Geef de Phone en LastName weer van alle klanten. 

C. Geef de Phone en LastName weer van alle klanten met FirstName ‘Nikkt’. 
D. Geef de Dateln en DateOut weer van alle orders van meer dan roo euro. 
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Geef de Phone en FirstName weer van alle klanten die een voornaam hebben 
die begint met ‘B’. 

Geef de Phone en FirstName weer van alle klanten die een achternaam hebben 
waar ‘cat’ in voorkomt. 

Geef de Phone, FirstName en LastName weer van alle klanten van wie het twee- 
de en derde cijfer in het telefoonnummer 23 is. 

Bepaal de maximale en minimale TotalAmount. 

Bepaal het gemiddelde van TotalAmount. 

Tel het aantal klanten. 

Groepeer de klanten op LastName en dan op FirstName. 

Tel het aantal klanten voor elke mogelijke combinatie van LastName en 
FirstName. 

Geef de FirstName en LastName weer van alle klanten die ooit een order heb- 
ben geplaatst met een TotalAmount van meer dan roo. Gebruik een subquery. 
Geef de resultaten weer gesorteerd in oplopende volgorde op LastName en dan 
in aflopende volgorde op FirstName. 

Geef de FirstName en LastName weer van alle klanten die ooit een order plaats- 
ten met een TotalAmount van meer dan roo. Gebruik een join. Geef de resul- 
taten weer gesorteerd in oplopende volgorde op LastName en dan in aflopende 
volgorde op FirstName. 

Geef de FirstName en LastName weer van alle klanten die ooit een order plaats- 
ten die een item bevat met de naam ‘Dress Shirt’. Gebruik een subquery. Geef 
de resultaten weer gesorteerd in oplopende volgorde op LastName en dan in af- 
lopende volgorde op FirstName. 

Geef de FirstName en LastName weer van alle klanten die ooit een order plaats- 
ten die een item bevat met de naam ‘Dress Shirt. Gebruik een join. Geef de 
resultaten weer gesorteerd in oplopende volgorde op LastName en dan in aflo- 
pende volgorde op FirstName. 

Geef de FirstName, LastName en TotalAmount weer voor alle klanten die ooit 
een order plaatsten die een item bevat met de naam ‘Dress Shirt’. Gebruik een 
join met een subquery. Geef de resultaten weer gesorteerd in oplopende volg- 
orde op LastName en dan in aflopende volgorde op FirstName. 


Importbedrijf Morgan 


Importbedrijf Morgan koopt antieke voorwerpen en meubilair in Azië en verscheept 
deze naar een warenhuis in Los Angeles. Meneer Morgan gebruikt een database voor 
het bijhouden van een lijst van gekochte items, verscheepte ladingen en items in la- 
dingen. Zijn database omvat de volgende tabellen: 
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SHIPMENT (Number, Shipper, DepartureDate, ArrivalDate, 
InsuredValue) 

SHIPMENT_ITEM (Number, Item, Aantal, Value) 

ITEM_ PURCHASE (Item, Store, Aantal, City, Date, 
LocalCurrencyAmt, ExchangeRate) 


Schrijf SQL-statements die de volgende informatie produceren: 


lee 


ed 


EE 
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Geef alle gegevens uit alle tabellen weer. 
Geef Number en Shipper weer van alle verscheepte ladingen. 
Geef Number en Shipper weer van alle verscheepte ladingen met een verzeker- 
de waarde (InsuredValue) groter dan ro.ooo. 
Geef Number en Shipper weer van alle exporteurs van wie de naam begint met 
‘AB’. 
Neem aan dat DepartureDate en ArrivalDate de indeling MM/DD/JJ hebben. 
Geef Number, Shipper en ArrivalDate weer van alle ladingen die zijn verscheept 
(DepartureDate) in december. 
Neem aan dat DepartureDate en ArrivalDate de indeling MM/DD/JJ hebben. 
Geef Number, Shipper en ArrivalDate weer van alle ladingen die zijn verscheept 
(DepartureDate) op de tiende dag van welke maand dan ook. 
Bepaal de maximale en minimale InsuredValue. 
Bepaal het gemiddelde van Insured Value. 
Tel het aantal verscheepte ladingen. 
Geef Item en Store weer, samen met een berekende kolom met de naam Std- 


CurrencyAmount die gelijk is aan LocalCurrencyAmt maal de ExchangeRate, 
voor alle rijen van ITEM_PURCHASE. 


Groepeer de gekochte items op City en Store. 
Tel het aantal aankopen voor elke mogelijke combinatie van City en Store. 


„ Geef Shipper en DepartureDate weer van alle verscheepte ladingen die een item 


bevatten met een waarde van 1ooo of meer. Gebruik een subquery. Geef de re- 
sultaten weer gesorteerd in oplopende volgorde op Shipper en dan in aflopende 
volgorde op DepartureDate. 

Geef Shipper en DepartureDate weer van alle verscheepte ladingen die een item 
bevatten met een waarde van rooo of meer. Gebruik een join. Geef de resultaten 
weer gesorteerd in oplopende volgorde op Shipper en dan in aflopende volgorde 
op DepartureDate. 

Geef Shipper en DepartureDate weer van alle verscheepte ladingen die een item 
bevatten dat in Singapore is gekocht. Gebruik een subquery. Geef de resultaten 
weer gesorteerd in oplopende volgorde op Shipper en dan in aflopende volgorde 
op DepartureDate. 

Geef Shipper en DepartureDate weer van alle verscheepte ladingen die een item 
bevatten dat in Singapore is gekocht. Gebruik een join. Geef de resultaten weer 
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gesorteerd in oplopende volgorde op Shipper en dan in aflopende volgorde op 


DepartureDate. 

Geef Shipper, DepartureDate van de verscheepte lading en Value weer van alle 
items die in Singapore zijn gekocht. Gebruik een combinatie van een join en 
een subquery. Geef de resultaten weer gesorteerd in oplopende volgorde op 


Shipper en dan in aflopende volgorde op DepartureDate. 
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Databases ontwerpen 


De vier hoofdstukken in deel 2 bespreken de principes en technieken die te maken 
hebben met het ontwerpen van databases. Hoofdstuk 3 en 4 beschrijven het ont- 
werpen van databases op basis van bestaande gegevensbestanden, zoals spread- 
sheets, tekstbestanden en uittreksels van databases. We beginnen in hoofdstuk 3 
met de definitie van het relationele model en bespreken normalisatie. Normalisatie 
is een proces dat relaties transformeert zodanig dat er minder problemen zijn bij het 
wijzigen van de gegevens in de database. We gebruiken de principes van de nor- 
malisatie daarna in hoofdstuk 4 als leidraad voor het ontwerpen van databases op 
basis van bestaande gegevens. 

Hoofdstuk 5 en 6 gaan in op het ontwerpen van databases bij het ontwikkelen 
van nieuwe informatiesystemen. Hoofdstuk 5 beschrijft het entiteit-relatiediagram 
— een hulpmiddel dat wordt gebruikt om plannen te maken voor het opzetten van 
databaseontwerpen. Je zult zien dat dergelijke diagrammen worden ontwikkeld 
door het analyseren van formulieren, rapporten en andere informatiesysteemeisen. 
Hoofdstuk 6 sluit dit deel af met een beschrijving van technieken voor het omzetten 
van entiteit-relatiediagrammen ín relationele databaseontwerpen. 


Hoofdstuk 3 
Het relationele model en 
normalisatie 


In hoofdstuk 1 zag je dat databases op drie manieren kunnen ontstaan: op basis van 
bestaande gegevens, bij het ontwikkelen van nieuwe informatiesystemen en als het 
resultaat van het herontwerpen van bestaande databases. We gaan in dit hoofdstuk en 
het volgende in op het ontwerpen van databases op basis van bestaande gegevens, 
zoals spreadsheets of uittreksels van bestaande databases. 

We gaan er in hoofdstuk 3 en 4 van uit dat je een of meer tabellen met gegevens 
vanuit een zekere bron hebt gekregen en dat je deze in een nieuwe database moet 
opslaan. De vraag is: moeten deze gegevens in hun huidige vorm worden opgeslagen, 
of moeten ze eerst worden omgezet voordat ze worden opgeslagen? Kijk bijvoorbeeld 
eens naar de twee tabellen in Figuur 3-1. Dat zijn de tabellen ARTIKEL en BESTELLING _ 
ITEM die in de database uit hoofdstuk 2 werden gebruikt. 
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Je kunt de nieuwe database voor het opslaan van deze gegevens zo ontwerpen dat zij 
twee verschillende tabellen heeft, of je kunt de tabellen samenvoegen tot een data- 
base met maar een tabel. Je geniet bepaalde voordelen als je besluit een bepaald ont- 
werp te gebruiken, maar daar staan nadelen tegenover. Het doel van dit hoofdstuk is 
je te helpen deze voor- en nadelen te begrijpen. 


ARTIKEL BESTELLING ITEM 
YP Artikelnummer U Bestellingnummer 
Artikelomschrijving Y Artikelnummer 
Afdeling Aantal 


Inkoper Stukprijs 
Totaalprijs 


Figuur 3-1 Hoeveel tabellen? 


De vraag of je een of twee tabellen moet maken ziet er niet moeilijk uit. Je kunt je 
afvragen waarom we twee hoofdstukken nodig hebben om deze te beantwoorden. 
De werkelijkheid is echter dat zelfs een enkele tabel verbazingwekkend ingewik- 
keld kan zijn. Kijk bijvoorbeeld eens naar de tabel in Figuur 3-2, die uit een bedrijfs- 
database geëxtraheerde voorbeeldgegevens toont. Deze eenvoudige tabel heeft drie 
kolommen: de naam van de inkoper, het artikelnummer van de producten die door 
de inkoper worden ingekocht en de namen van de hoofdvakken in de opleiding van 
de inkoper. Inkopers kunnen voor meer dan een artikelnummer verantwoordelijk 
zijn en ze kunnen meer hoofdvakken hebben. 


PRODUCT_INKOPER 

Artikelnummer Ei Hoofdvak 
101100 pemaesciedens 
101100 Informatiesystemen 
101200 Kunstgeschiedenis 
101200 Informatiesystemen 
| 5| Peter Jansen 100100 | Bedrijfskunde 


| _6[Peterjansen | 100200 Bedrijfskunde 


Figuur 3-2 PRODUCT_INKOPER — een erg vreemde tabel 


1 | Najma Barends 


Najma Barends 
Najma Barends 
|_4 | Najma Barends 


J 


Om te begrijpen waarom dit een vreemde tabel is, moet je je eens voorstellen 
dat Najma Barends een nieuw artikelnummer inkoopt, bijvoorbeeld 101300. Het 
is duidelijk dat we een nieuwe rij nodig hebben voor het nieuwe artikelnummer. 
Als we echter maar één nieuwe rij toevoegen, bijvoorbeeld de rij (‘Najma Barends’, 
ro13oo, ‘Kunstgeschiedenis'), dan lijkt het alsof ze product 101300 wel inkoopt met 
het hoofdvak Kunstgeschiedenis, maar niet met het hoofdvak Informatiesystemen. 
We moeten twee rijen toevoegen om een dergelijke onlogische toestand te vermij- 
den: (‘Najma Barends’, ro13oo, ‘Kunstgeschiedenis’) en (‘Najma Barends’, 1o13oo, 
‘Informatiesystemen'). 
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Dat is nogal raar. Waarom zouden we twee rijen gegevens moeten toevoegen, alleen 
om te registreren dat een inkoper er een nieuw artikelnummer bij heeft? Verder 
geldt dat we maar één rij zouden moeten toevoegen als Peter Jansen hetzelfde pro- 
duct zou inkopen, maar dat we vier nieuwe rijen zouden moeten toevoegen als een 
inkoper met vier hoofdvakken dat product zou krijgen. 

Hoe meer we over de tabel in Figuur 3-2 nadenken, hoe vreemder deze wordt. Je 
zult later in dit hoofdstuk zien dat het probleem ontstaat doordat de tabel een zoge- 
heten meerwaardige afhankelijkheid heeft. Het mooie is dat je ook leert dat probleem 
op te lossen. Maar voor het zover is, moeten we eerst een aantal vaktermen leren 
kennen. 


3.1 Terminologie voor het relationele model 


Figuur 3-3 laat de belangrijkste termen zien die voor het relationele model worden 
gebruikt. Als je hoofdstuk 3 en 4 uit hebt, zou je in staat moeten zijn elk van deze 
termen te definiëren en uit te leggen hoe deze in verband staan met het ontwerpen 
van relationele databases. Je kunt deze lijst met termen gebruiken als een controle- 
mogelijkheid om te zien hoe ver je begrip reikt. 


Relatie f 
Functionele afhankelijkheid 
Determinant 

Kandidaatsleutel 
Samengestelde sleutel 

Primaire sleutel 

Surrogaatsleutel 

| Externe sleutel 

Referentiële integriteitsvoorwaarde 
| Normaalvorm 

Meerwaardige afhankelijkheid 
Figuur 3-3 Belangrijke termen voor het relationele model 


3.1.1 Relatie 
Tot dusver hebben we de termen tabel en relatie door elkaar gebruikt, alsof ze hetzelf- 


de betekenen. Een relatie is echter in feite een speciaal geval van een tabel. Dat wil 
zeggen dat elke relatie een tabel is, maar niet elke tabel is een relatie. Codd heeft de 
kenmerken van een relatie gedefinieerd in zijn artikel uit 197o, dat als basis diende 
voor het relationele model. Deze kenmerken zijn samengevat in Figuur 3-4. 


1 _E.F. Codd (juni 1970), ‘A Relational Model of Data for Large Shared Databanks', Communications of 
the ACM, pagina 377-387. 
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Kenmerken van een relatie: 
Rijen bevatten gegevens over een entiteit. 
Kolommen bevatten gegevens over attributen van de entiteit. 
Alle items in een kolom zijn van hetzelfde soort. 

Elke kolom heeft een unieke naam. 

Cellen van de tabel bevatten enkelvoudige gegevens. 

De volgorde van de kolommen is niet van belang. 

De volgorde van de rijen is niet van belang. 
Er mogen geen identieke rijen voorkomen. 


Figuur 3-4 Kenmerken van een relatie 


Opmerking 

Met de term entiteit in Figuur 3-4 bedoelen we een instantie van een of ander identificeerbaar ding. Een 
klant, een verkoper, een bestelling, een onderdeel of een leasecontract zijn allemaal voorbeelden van 
entiteiten. We definiëren het begrip entiteit nauwkeuriger als we het entiteit-relatiemodel introduceren 
in hoofdstuk 5. je kunt je een entiteit tot dan voorstellen als een of ander identificeerbaar ding waarover 
gebruikers gegevens willen opslaan. 


3.1.2 Kenmerken van relaties 

Wil een tabel een relatie zijn, dan moeten de rijen van deze tabel om te beginnen 
gegevens opslaan over een entiteit. De kolommen van de tabel moeten gegevens op- 
slaan over de eigenschappen van deze entiteiten. Alle waarden in een kolom moe- 
ten bovendien van hetzelfde soort zijn in een relatie. Bevat de tweede kolom van de 
eerste rij van een relatie bijvoorbeeld Voornaam, dan zal de tweede kolom van elke 
rij in de relatie Voornaam bevatten. De namen van de kolommen moeten verder 


uniek zijn: er mogen in dezelfde relatie geen twee kolommen voorkomen die de- 
zelfde naam hebben. 


Opmerking 

Kolommen in verschillende relaties mogen wel dezelfde naam hebben. je zag in hoofdstuk 2 bijvoorbeeld 
twee relaties met een kolom met de naam Artikelnummer. Waar het gevaar van verwarring bestaat, 
plaatsen we de naam van de relatie, gevolgd door een punt, voor de naam van de kolom. De naam 

van de kolom Artikelnummer in de relatie ARTIKEL wordt dus ARTIKEL Artikelnummer en kolom C1 van 

de relatie R1 wordt R1.C1 genoemd. Namen van relaties zijn uniek binnen een database en namen van 
kolommen zijn uniek binnen een relatie — elke kolom in de database kan dus op een unieke manier 
worden geïdentificeerd via de combinatie van de namen van de relatie en de kolom. 


Elke cel van een relatie bevat slechts een enkele waarde of een enkel item — meer 
waarden of items zijn niet toegestaan. De tabel in Figuur 3-6 is geen relatie, want 
de waarden in Telefoon voor de werknemers Groot en Barends slaan meer dan een 
telefoonnummer op. 

De volgorde van de rijen en de volgorde van de kolommen zijn niet van belang 
in een relatie. De volgorde van de rijen of de kolommen kan geen informatie over- 
dragen. De tabel in Figuur 3-6 is geen relatie, want de gegevens voor de werknemers 
Groot en Gringhuis vereisen een specifieke indeling van de rijen. Zou de volgorde 
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van de rijen in deze tabel gewijzigd worden, dan zouden we niet weten bij welke 
werknemer de opgegeven fax- en mobiele nummers horen. 

Het laatste kenmerk in Figuur 3-4 bepaalt ten slotte dat geen twee rijen in een ta- 
bel identiek mogen zijn, wil deze tabel een relatie zijn. Je zag in hoofdstuk 2 dat som- 
mige SQL-statements echter tabellen kunnen produceren die gedupliceerde rijen 
bevatten. Je kunt in dergelijke gevallen het sleutelwoord DISTINCT gebruiken om 
zeker te stellen dat alle rijen uniek zijn. Dergelijke gedupliceerde rijen treden echter 
alleen op als resultaat van een SQL-bewerking. Tabellen die je zelf ontwerpt om in de 
database te worden opgenomen, mogen nooit gedupliceerde rijen bevatten. 


Productie 
Wetsafdeling 


Jansen 
Gringhuis 


Mobiel: 
T@ergens.com 
EC@ergens.com 


266-9987 
555-7171 
444-9980 
767-0900 


Werknemer _ [voornaam teen [afdeling 
Nummer 
100 Jan [johansen Boekhouding JJ@ergens.com |236-9987 
200 Marie Abelse _ {Financiën MA@ergens.com | 444-8898 
300 Lisa Smeets Financiën LS@ergens.com |777-0098 
400 Tom Groot Boekhouding TC@ergens.com [236-9987, 
266-9987, 
es ES Las 555-7171 
500 Tom Jansen __ Productie _|m@ergens.com 444-9980 
600 Ellie Gringhuis _ Wetsafdeling EC@ergens.com | 767-0900 
700 Richard Barends Wetsafdeling RB@ergens.com | 767-0900, 
J 767-0011 | 
Figuur 3-5 Tabel met meer items per cel 
Werknemer _ [Voornaam Achternaam Afdeling Telefoon 
Nummer | 
100 Jan Johansen Boekhouding jJ@ergens.com | 236-9987 
200 Marie Abelse Financiën MA@ergens.com | 444-8898 
300 isa Smeets Financiën LS@ergens.com | 777-0098 ai 
400 Tom Groot Boekhouding 236-9987 


236-9987 


oo Richard Barends Wetsafdeling 


Mobiel: 


555-7171 


Figuur 3-6 Tabel met een vereiste volgorde voor de rijen 


Opmerking 


Pas op voor de volgende valkuil: elke cel van een relatie mag weliswaar maar een enkele waarde 


bevatten, dat betekent niet dat de waarden allemaal even lang moeten zijn. De lengte van de kolom 


RB@ergens.com | 767-0900 


Opmerkingen varieert van rij tot rij in de tabel in Figuur 3-7, maar deze tabel is wel degelijk een relatie. 
De lengte van de opmerkingen mag dan wel verschillen, er is maar één opmerking per cel. 
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Werknemer 
Nummer 


Voornaam |Achter- Afdeling 
naam 


Telefoon _|Opmerkingen 
| 


100 Jan Johansen [Boekhouding [yy@ergens.com |236-9987 |Is in maart op 
‚de afdeling 
Boekhouding 
aangenomen, 
nadat hij | 
zijn diploma | 
| behaalde op de | 
| | avondschool. _ 
200 Î Abelse Financiën |MA@ergens.com |-444-8898 mi | 
300 i _{smeets Financiën LS@ergens.com |777-0098 Eet 
00 Groot | Boekhouding [TC@ergens.com | 236-9987 


4 
Jansen {Productie [T@ergens.com _|444-9980 
Ellie Gringhuis | Wetsafdeling |ec@ergens.com |767-0900 
Richard Barends Wetsafdeling | RB@ergens.com | 767-0900 | Fulltime 
| | consulent voor 
de Wetsafdeling. 
| Heeft een vast 


salaris. 


Figuur 3-7 Relatie met een kolom met een variabele lengte 


3.1.3 Aanvullende terminologie 

De kolommen van een relatie heten volgens de definitie van Codd attributen en de 
rijen tupels. In de praktijk worden de termen kolom, rij en tabel gebruikt in plaats 
van de termen attribuut, tupel en relatie — ook al hoeft een tabel niet altijd een relatie 
te zijn. De termen relatie en tabel mogen in de meeste conversaties dan ook als sy- 
noniem worden gezien. We zullen tabel en relatie in de rest van dit boek als synonie- 
men gebruiken. 

Er wordt ook nog een derde reeks termen gebruikt. Sommige vakmensen gebrui- 
ken de termen bestand, veld en record voor de termen tabel, kolom en rij. Deze termen 
zijn afkomstig uit de traditionele gegevensverwerking en ze worden veel gebruikt in 
verbinding met oudere systemen. Er zijn mensen die deze termen door elkaar ge- 
bruiken. Je kunt iemand bijvoorbeeld horen zeggen dat een relatie een bepaalde ko- 
lom en 47 records bevat. Deze drie reeksen termen vatten we samen in Figuur 3-8. 


Tabel___|Kolom [rj | 
Attibuut 
Record 


Figuur 3-8 Drie reeksen equivalente termen 


3.1.4 Functionele afhankelijkheden 
Functionele afhankelijkheden staan centraal in het proces van het ontwerpen van da- 


tabases en het is van groot belang dat je ze begrijpt. We leggen het concept eerst in 
algemene termen uit en bekijken daarna twee voorbeelden. 
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Stel dat je dozen koekjes koopt en iemand je vertelt dat elke doos € 5 kost. Nu je dat 
weet, kun je de kosten van meer dozen berekenen met de formule: 


KostenkKoekjes = AantalDozen x €5,- 


De relatie tussen KostenKoekjes en AantalDozen kunnen we op een meer algemene 
manier uitdrukken door te zeggen dat KostenKoekjes afhankelijk is van AantalDozen. 
Een dergelijke verklaring laat ons weten wat de aard is van de relatie tussen Kosten- 
Koekjes en AantalDozen, hoewel deze ons de formule niet geeft. We kunnen meer 
formeel zeggen dat KostenKoekjes functioneel afhankelijk is van AantalDozen. Een 
dergelijke uitspraak kun je als volgt schrijven: 


AantalDozen — KostenKoekjes 


Deze uitdrukking kun je ook lezen als ‘AantalDozen bepaalt KostenKoekjes'. De vari- 
abele aan de linkerkant, in dit geval AantalDozen, heet de determinant. 

Een ander voorbeeld is dat we het totale bedrag van een order kunnen berekenen 
door het aantal items met de Stukprijs te vermenigvuldigen: 


Totaalprijs = Aantal * Stukprijs 


We zeggen in dit geval dat Totaalprijs functioneel afhankelijk is van Aantal en van 
Stukprijs, of: 


(Aantal, Stukprijs) — Totaalprijs 
De samenstelling (Aantal, Stukprijs) is hier de determinant van Totaalprijs. 


Functionele afhankelijkheden die geen gelijkheden zijn 

Algemeen gezegd bestaat er een functionele afhankelijkheid als de waarden van een 
of meer attributen worden bepaald door de waarde van een ander attribuut. Er be- 
staan veel functionele afhankelijkheden die geen gelijkheid omvatten. Laten we daar 
eens een voorbeeld van bekijken. Stel dat je weet dat een zak rode, blauwe of gele 
objecten bevat en dat je weet dat de rode objecten 5 pond wegen, de blauwe objecten 
3 pond en de gele objecten 7 pond. Als een vriendin in de zak kijkt, een object ziet en 
je de kleur daarvan vertelt, dan kun je haar vertellen wat het gewicht van het object 
is. We kunnen dat als volgt formaliseren: 


Objectkleur — Gewicht 
We kunnen dus zeggen dat Gewicht functioneel afhankelijk is van Objectkleur en 
dat Objectkleur Gewicht bepaalt. Deze relatie bevat geen rekenkundige gelijkheid, 
maar de functionele afhankelijkheid is hier wel van toepassing. Je kunt het gewicht 


van het object bepalen op basis van de waarde van Objectkleur. Zouden we verder 
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ook weten dat de rode objecten ballen zijn en dat de blauwe en de gele objecten ku- 
bussen zijn, dan zouden we ook kunnen zeggen: 


Objectkleur > Vorm 


Vorm wordt dus bepaald door Objectkleur. We kunnen deze twee gegevens samen- 
voegen en zeggen: 


Objectkleur — (Gewicht, Vorm) 
Objectkleur bepaalt dus Gewicht en Vorm. 


We kunnen deze feiten ook als volgt representeren door ze in een tabel op te ne- 
men, zie Figuur 3-9. 


Objectkleur 


Kubus 
Figuur 3-9 Relatie tussen objectkleur, gewicht en vorm 


Deze tabel voldoet aan alle in Figuur 3-4 genoemde voorwaarden en is dus een re- 
latie. Er is feitelijk slechts één reden voor het hebben van een relatie, namelijk het 
opslaan van instanties van functionele afhankelijkheden. Zou er een formule be- 
staan om Vorm en Gewicht op de een of andere manier te berekenen op basis van 
Objectkleur, dan zouden we geen tabel nodig hebben. We zouden dan simpelweg de 
berekening uitvoeren. Zou er een formule bestaan waarmee we Werknemernaam en 
DatumAangenomen kunnen berekenen op basis van Werknemernummer, dan zou- 
den we geen WERKNEMER-relatie nodig hebben. Een dergelijke formule bestaat 
echter niet en we zullen de combinaties van Werknemernummer, Werknemernaam 
en DatumAangenomen dan ook moeten opslaan in de rijen van een relatie. 


Samengestelde functionele afhankelijkheden 
De determinant van een functionele afhankelijkheid kan uit meer attributen be- 
staan. Een cijfer voor een vak wordt bijvoorbeeld zowel bepaald door de student als 
het vak, oftewel (Studentnaam, Vaknaam) > Cijfer. De determinant heet in dat geval 
een samengestelde determinant. 

Merk op dat zowel de student als het vak nodig is om het cijfer te bepalen. Alge- 
meen gezegd: 

Als (A, B) > C zal C niet alleen door A of door B worden bepaald. 

Als A > (B, C), dan zal het zo zijn dat A > B en A > C. 


Bedenk zelf een paar voorbeelden van beide gevallen en werk deze door om te begrij- 
pen waarom dat zo is. 
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Om functionele afhankelijkheden nog beter te begrijpen, kijken we in de volgende 
paragrafen naar de tabellen ARTIKEL en BESTELLING_ITEM uit Figuur 3-1. 


3.1.5 Functionele afhankelijkheden in de tabel ARTIKEL 

Willen we functionele afhankelijkheden vinden in een tabel, dan moeten we de vol- 
gende vraag stellen: is er een kolom waarvan de waarde wordt bepaald door een an- 
dere kolom? Kijk bijvoorbeeld naar de waarden van de tabel ARTIKEL uit Figuur 
3-10. 


Artikelnummer | Artikelomschrijving [ Afdeling Inkoper 
100100 Standaard SCUBA, geel Watersport Peter Jansen 
100200 | Standaard SCUBA, magenta watersport | Peter Jansen 
101100 _| Ouikmasker, small, helder | Watersport | Najma Barends 
101200 Ouikmasker, medium, helder Watersport Najma Barends 

201000 Halvekoepeltent Í Camping _| Charlotte Laan 

|_202000 _| Grondzeil halvekoepeltent E Camping de _{ Charlotte Laan 

| 301000 | Lichtgewicht klimharnas Klimmen k [johan Martens 
302000 Karabijnsluiting, ovaal | Klimmen _ johan Martens Ber 


Figuur 3-10 Tabel ARTIKEL 


Bekijk de laatste twee kolommen. Kun je een unieke waarde voor Inkoper bepalen 
als je de waarde van Afdeling kent? Nee, dat kun je niet, want een afdeling kan meer 
dan een inkoper hebben. ‘Watersport’ wordt in deze voorbeeldgegevens geassocieerd 
met Peter Jansen en Najma Barends. Inkoper wordt dus niet functioneel bepaald 
door Afdeling. 

Maar hoe staat het met het omgekeerde? Wordt Afdeling bepaald door Inkoper? 
De naam Johan Martens is bijvoorbeeld telkens gekoppeld aan dezelfde afdeling. 
Het antwoord lijkt ja. De naam Charlotte Laan is ook steeds weer gekoppeld aan de- 
zelfde afdeling. Hetzelfde geldt voor de andere inkopers. Als we aannemen dat deze 
gegevens representatief zijn, dan wordt Afdeling inderdaad bepaald door Inkoper en 
kunnen we dus het volgende schrijven: 


Inkoper — Afdeling 


Zijn er nog meer kolommen die door Inkoper worden bepaald? Kennen we de waarde 
van Artikelnummer als we de waarde van Inkoper kennen? Nee, die kennen we niet, 
want er zijn veel verschillende artikelnummers aan een bepaalde inkoper toegekend. 
Wordt Artikelomschrijving bepaald door Inkoper? Nee, want een gegeven waarde 
voor Inkoper komt voor met veel verschillende waarden van Artikelomschrijving. 


Hoe staat het verder met de andere kolommen? Het blijkt dat we de waarden van alle 
andere kolommen ook kennen, als we de waarde van Artikelnummer kennen. Met 
andere woorden: 


Artikelnummer — Artikelomschrijving 
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Opmerking 

Zoals we al opmerkten bij de functionele afhankelijkheid inkoper — Afdeling, is een Inkoper altijd aan 

een en dezelfde waarde van Afdeling gekoppeld. Merk op dat een inkoper meer dan eens in de tabel kan 
voorkomen, maar dat de inkoper in dat geval altijd aan dezelfde afdeling is gekoppeld. Dit geldt voor alle 
functionele afhankelijkheden. Als A > B, dan zal elke waarde van A altijd aan een en dezelfde waarde van 
B zijn gekoppeld. Een bepaalde waarde van A kan meer dan eens in de relatie voorkomen, maar is in dat 


geval altijd aan dezelfde waarde van B gekoppeld. Merk verder op dat het omgekeerde niet altijd hoeft te 
gelden. Een waarde van B kan aan veel waarden van A zijn gekoppeld, als A — B. 


want er zal maar één waarde van Artikelomschrijving zijn voor een gegeven waarde 
van Artikelnummer. 


Artikelnummer — Afdeling 


Want er zal maar één waarde van Afdeling zijn voor een gegeven waarde van 
Artikelnummer. 


Artikelnummer — Inkoper 


Want er zal maar één waarde van Inkoper zijn voor een gegeven waarde van Artikel- 
nummer. We kunnen deze drie statements schrijven als: 


Artikelnummer > (Artikelomschrijving, Afdeling, Inkoper) 


Alle andere kolommen worden, om dezelfde redenen, ook bepaald door Artikel- 
omschrijving. We kunnen dus ook schrijven: 


Artikelomschrijving > (Artikelnummer, Afdeling, Inkoper) 
Samenvattend, de functionele afhankelijkheden van de tabel ARTIKEL zijn: 


Artikelnummer > (Artikelomschrijving, Afdeling, Inkoper) 
Artikelomschrijving > (Artikelnummer, Afdeling, Inkoper) 


Inkoper — Afdeling 
Opmerking 


Het is niet altijd mogelijk functionele afhankelijkheden te bepalen aan de hand van bestaande 
voorbeeldgegevens. je hebt misschien geen voorbeeldgegevens of slechts een paar rijen die niet 
representatief zijn voor alle gegevenswaarden. In dergelijke gevallen worden de gebruikers die veel 
van de toepassingen van de data weten, ondervraagd. Je zou voor de tabel ARTIKEL vragen stellen zoals: 
‘Is een inkoper altijd aan dezelfde afdeling gekoppeld?’ en ‘Kan een afdeling meer dan één inkoper 
hebben? De antwoorden op dergelijke vragen zijn in-de meeste gevallen betrouwbaarder dan de 
voorbeeldgegevens. Vertrouw in geval van twijfel op de gebruikers. 


HET RELATIONELE MODEL EN NORMALISATIE 


3.1.6 Functionele afhankelijkheden in de tabel BESTELLING ITEM 
Kijk nu eens naar de tabel BESTELLING_ITEM in Figuur 3-11. 


Ws BESTELLING _ITEM 

‚_Bestellingnummer Artikelnummer Aantal [ 5 Stukprijs | Totaalprijs 
1000 201000 | 1 c300,00_ | €300,00 
1000 |__202000 1 € 130,00 € 130,00 
2000 |__101100 4 €50,00 | _C200,00 

| 2000 101200 | 2 € 50,00 _c100,00 | 

En 3000 100200 1 € 300,00 c300,00_ | 

| VOE BOT nt ORE [__€5000 | _c100,00 
3000 101200 1 |__€50,00 | _ €50,00 / 


Figuur 3-11 Tabel BESTELLING-ITEM 


Wat zijn de functionele afhankelijkheden in deze tabel? Begin aan de linkerkant. Is 
er een andere kolom die wordt bepaald door Bestellingnummer? Artikelnummer 
wordt daar niet door bepaald, want er zijn meer artikelnummers aan een gegeven 
bestelling gekoppeld. Aantal, Stukprijs en Totaalprijs worden er om dezelfde reden 
ook niet door bepaald. Hoe staat het met Artikelnummer? Bestellingnummer wordt 
niet door Artikelnummer bepaald, want er zijn diverse bestellingnummers aan een 
gegeven Artikelnummer gekoppeld. Aantal en Totaalprijs worden er om dezelfde re- 
den ook niet door bepaald. 

Hoe staat het met Artikelnummer en Stukprijs? Het lijkt op basis van deze gege- 
vens dat: 


Artikelnummer — Stukprijs 


Maar dat zal misschien niet altijd het geval zijn. We weten in feite dat de prijzen kun- 
nen veranderen nadat een bestelling is verwerkt. Er kan bovendien een speciale prijs 
gelden voor een bestelling, vanwege een uitverkoop of actie. We moeten de prijs van 
een bepaald Artikelnummer aan een specifieke bestelling koppelen om nauwgezet 
te registreren wat een klant feitelijk heeft betaald. Dat wil zeggen: 


(Bestellingnummer, Artikelnummer) >» Stukprijs 


Als we de andere kolommen bekijken, blijkt dat er niets anders wordt bepaald door 
Aantal, Stukprijs en Totaalprijs. Je komt tot deze conclusie door naar de voorbeeldge- 
gevens te kijken. Je kunt deze conclusie bovendien nog eens bevestigen door over de 
aard van het verkopen na te denken. Zal een Bestellingnummer of een Artikelnum- 
mer ooit worden bepaald door een Aantal van 2? Natuurlijk niet. Bestellingnummer 
en Artikelnummer worden niet bepaald door Aantal. 

Je zou verder ook op geen enkele logische manier kunnen concluderen wat een 
Bestellingnummer was als de prijs van een item bekend is. Bestellingnummer 
of Artikelnummer worden dus niet bepaald door Stukprijs. Hetzelfde geldt 
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voor Totaalprijs. Het blijkt dat geen enkele kolom een determinant is in de tabel 
BESTELLING. ITEM. 

Maar hoe staat het met paren kolommen? We weten al dat (Bestellingnummer, 
Artikelnummer) > Stukprijs. Als we de gegevens bekijken, zien we dat (Bestelling. 
nummer, Artikelnummer) de twee andere kolommen ook bepaalt. Dat wil zeggen: 


(Bestellingnummer, Artikelnummer) — (Aantal, Stukprijs, 
Totaalprijs) 


Deze functionele afhankelijkheid is zinvol. Deze betekent dat er maar één hoeveel. 
heid, Stukprijs en Totaalprijs is voor een specifieke bestelling en een specifiek item 
in die bestelling. 


Totaalprijs wordt berekend via de formule Totaalprijs = Aantal * Stukprijs. Dit be- 
tekent dat: 


(Aantal, Stukprijs) — Totaalprijs 
Samenvattend, de functionele afhankelijkheden in BESTELLING_ITEM zijn: 


(Bestellingnummer, Artikelnummer) — (Aantal, Stukprijs, 


Totaalprijs) 
(Aantal, Stukprijs) > Totaalprijs 


Geen enkele andere vaardigheid is belangrijker voor het ontwerpen van databases 
dan in staat zijn functionele afhankelijkheden te identificeren. Wees er daarom ze- 
ker van dat je het materiaal in deze paragraaf goed begrijpt. Werk probleem 58 en 
59 en de projecten Marcia's Chemische Reiniging en Importbedrijf Morgan aan het 
eind van dit hoofdstuk door. Vraag je docent zo nodig om hulp. Je moet functionele 
afhankelijkheden begrijpen en je moet ermee kunnen werken. 


3.2 Wanneer zijn waarden van determinanten uniek? 


Je hebt in de vorige paragraaf misschien een onregelmatigheid opgemerkt. De de- 
terminanten van een functionele afhankelijkheid zijn soms uniek in een rela- 
tie — en soms ook niet. Kijk eens naar de relatie ARTIKEL, met de determinanten 
Artikelnummer, Artikelomschrijving en Inkoper. De waarden van Artikelnummer en 
Artikelomschrijving zijn beide uniek in de tabel ARTIKEL. Artikelnummer 1oo100 
komt bijvoorbeeld maar eenmaal voor. De Artikelomschrijving ‘Halvekoepeltent 
komt ook maar eenmaal voor. Het is verleidelijk op basis daarvan te concluderen dat 
de waarden van determinanten in een relatie altijd uniek zijn. Dat is echter niet waar. 

Inkoper is bijvoorbeeld een determinant, maar is niet uniek in ARTIKEL. De in- 
koper Charlotte Laan komt in twee verschillende rijen voor. Alle inkopers komen in 
deze voorbeeldgegevens in feite in twee verschillende rijen voor. 
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Een determinant is in werkelijkheid alleen uniek in een relatie als deze elke andere 
kolom in de relatie bepaalt. Artikelnummer bepaalt alle andere kolommen in de re- 
latie ARTIKEL. Artikelomschrijving bepaalt eveneens alle andere kolommen. Ze zijn 
dan ook beide uniek. Inkoper bepaalt echter alleen de kolom Afdeling. Artikelnum- 
mer en Artikelomschrijving worden er niet door bepaald. 

De determinanten in BESTELLING ITEM zijn (Bestellingnummer, Artikelnum- 
mer) en (Aantal, Stukprijs). (Bestellingnummer, Artikelnummer) zal uniek zijn in 
de relatie, want deze bepaalt alle andere kolommen. De samenstelling (Aantal, Stuk- 
prijs) bepaalt alleen Totaalprijs en zal dus niet uniek zijn in de relatie. 

Dat de waarden van determinanten in een relatie niet altijd uniek zijn, betekent 
dat je de determinanten van alle functionele afhankelijkheden niet kunt vinden door 
simpelweg naar unieke waarden te zoeken. Vraag in plaats daarvan ‘Is dezelfde waar- 
de overal waar deze in kolom A voorkomt aan dezelfde waarde in kolom B gekop- 
peld?’ als je wilt bepalen of kolom B door kolom A wordt bepaald. Is dat het geval, 
dan kan A een determinant zijn van B. Vergeet echter niet dat voorbeeldgegevens 
onvolledig (en daardoor niet representatief) kunnen zijn. De beste strategie is dus 
nadenken over de aard van de bedrijfsactiviteit waar de gegevens door worden gele- 
verd en de gebruikers vragen. 


3.3 Sleutels 


Het relationele model kent vele verschillende soorten sleutels: kandidaatsleutels, 
samengestelde sleutels, surrogaatsleutels en externe sleutels. We zullen elk van deze 
soorten sleutels hier definiëren. De definities van de sleutels zijn gebaseerd op het 
concept van functionele afhankelijkheid. Het is daarom belangrijk dat je dat concept 
begrijpt, voordat je verder leest. 

Een sleutel (of key) is in het algemeen een combinatie van een of meer kolom- 
men die wordt gebruikt voor het identificeren van specifieke rijen in een relatie. 
Sleutels die twee of meer kolommen omvatten, noemen we samengestelde sleutels 
of composite keys. 


3.3.1 Kandidaatsleutels 

Een kandidaatsleutel of candidate key is een determinant die alle andere kolom- 
men in een relatie bepaalt. De relatie ARTIKEL heeft twee kandidaatsleutels: 
Artikelnummer en Artikelomschrijving. Inkoper is een determinant, maar geen 
kandidaatsleutel, want deze bepaalt alleen Afdeling. 

De tabel BESTELLING_ITEM heeft maar een kandidaatsleutel: (Bestelling- 
nummer, Artikelnummer). De andere determinant in deze tabel, (Aantal, Stukprijs), 
is geen kandidaatsleutel, want deze bepaalt alleen Totaalprijs. 

Kandidaatsleutels identificeren een unieke rij in een relatie. Kennen we de waar- 
de van een kandidaatsleutel, dan kunnen we de ene — en enige — rij in de relatie vin- 
den die deze waarde bevat. Weten we bijvoorbeeld dat de waarde van Artikelnummer 
rooroo is, dan kunnen we precies één rij vinden in ARTIKEL. Weten we dat de waar- 
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den van Bestellingnummer en Artikelnummer (2000, rorroo) zijn, dan kunnen we 
ook weer precies één rij vinden in BESTELLING-ITEM. 


3.3.2 Primaire sleutels 

Een van de kandidaatsleutels wordt tijdens het ontwerpen van een database gese- 
lecteerd als de primaire sleutel of primary key. Deze term wordt gebruikt omdat het 
DBMS deze sleutel dan zal gebruiken als het eerste middel voor het zoeken van rijen 
in een tabel. Een tabel heeft maar één primaire sleutel. De primaire sleutel kan uit 
één kolom bestaan, of kan een samenstelling van kolommen zijn. 

We geven in dit boek de tabelstructuur soms aan door de naam van een tabel te 
schrijven, gevolgd door de namen van de kolommen van de tabel tussen haakjes. We 
onderstrepen in dat geval de kolom(men) die de primaire sleutel vormen. We kun- 
nen de structuur van ARTIKEL en BESTELLING _ITEM als volgt laten zien: 


ARTIKEL (Artikelnummer, Artikelomschrijving, Afdeling, Inkoper) 


BESTELLING ITEM (Bestellingnummer, Artikelnummer, Aantal, 
Stukprijs, Totaalprijs) 


Deze notatie betekent dat Artikelnummer de primaire sleutel is van ARTIKEL en dat 
(Bestellingnummer, Artikelnummer) de primaire sleutel is van BESTELLING ITEM. 


Opmerking 

Wal moet je doen als een tabel geen kandidaatsleutels heeft? Definieer in dat geval de primaire sleutel 
als de verzameling van alle kolommen in de tabel. De combinatie van alle kolommen in de tabel zal 
altijd uniek zijn, want er komen geen dubbele rijen voor in een opgeslagen relatie. Dat houdt in dat de 
combinatie van alle kolommen altijd een kandidaatsleutel is. 


3.3.3 Surrogaatsleutels 
Een surrogaatsleutel (of surrogate key) is een kunstmatige kolom die aan een tabel 
wordt toegevoegd om als primaire sleutel te fungeren. Het DBMS kent een unieke 
waarde aan een surrogaatsleutel toe als de rij wordt gemaakt. De toegekende waarde 
verandert nooit. 

Er worden surrogaatsleutels gebruikt als de primaire sleutel groot of onhandig is. 
Kijk bijvoorbeeld eens naar de relatie VERHUUR ITEM: 


VERHUUR ITEM (Straat, Plaats, Staat/Provincie, Lip/Postcode, 
Land, Verhuur Tarief) 


De primaire sleutel van deze tabel is (Straat, Plaats, Staat/Provincie, Zip/Postcode). 
Zoals je in hoofdstuk 6 zult zien, moet een primaire sleutel kort en, zo mogelijk, nu- 
meriek zijn om goede prestaties te bereiken. De hierboven gedefinieerde primaire 
sleutel van VERHUUR.ITEM is geen van beide. 


De ontwerpers van de database maken in dit geval waarschijnlijk een surrogaat- 
sleutel. De structuur van de tabel wordt dan: 
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VERHUUR ITEM (ItemlD, Straat, Plaats, Staat/Provincie, 
Zip/Postcode, Land, Verhuur Tarief) 


Het DBMS zal een numerieke waarde aan Item[D toekennen als een rij wordt ge- 
maakt. Met deze sleutel levert de database betere prestaties dan bij gebruik van de 
originele sleutel. Merk op dat waarden van surrogaatsleutels kunstmatig zijn en dat 
deze geen betekenis hebben voor de gebruikers. De waarden van surrogaatsleutels 
worden normaliter verborgen in formulieren en rapporten. 


3.3.4 Externe sleutels 

Een externe sleutel, vreemde sleutel of foreign key is een kolom of een samenstel- 
ling van kolommen die de primaire sleutel is van een andere tabel. AFDELING. 
AfdelingNaam is in de volgende twee tabellen de primaire sleutel van AFDELING. 
WERKNEMER. AfdelingNaam is een externe sleutel. We geven externe sleutels in dit 
boek cursief weer. 


AFDELING (AfdelingNaam, BudgetCode, ManagerNaam) 
WERKNEMER (Werknemernummer, Werknemernaam, AfdelingNaam) 


Externe sleutels drukken relaties uit tussen rijen van tabellen. De externe sleutel 
WERKNEMER.AfdelingNaam slaat bijvoorbeeld de relatie op tussen een werknemer 
en zijn of haar afdeling. 

Kijk nu eens naar de tabellen ARTIKEL en BESTELLING_ITEM.ARTIKEL. 
Artikelnummer is de primaire sleutel van ARTIKEL en BESTELLING ITEM. 
Artikelnummer is een externe sleutel. 


ARTIKEL (Artikelnummer, Artikelomschrijving, Afdeling, Inkoper) 
BESTELLING ITEM (Bestellingnummer, Artikelnummer, Aantal, 
Stukprijs, Totaalprijs) 


Merk op dat BESTELLING ITEM. Artikelnummer niet alleen een externe sleutel is, 
maar dat deze ook deel uitmaakt van de primaire sleutel van BESTELLING. ITEM. 
Dat komt soms voor, maar is niet vereist. 

We moeten in de meeste gevallen zeker stellen dat de waarden van een externe 
sleutel overeenkomen met geldige waarden van de betreffende primaire sleutel. We 
moeten er bij de tabellen ARTIKEL en BESTELLING_ITEM voor zorgen dat elke 
waarde van BESTELLING. ITEM Artikelnummer overeenkomt met een waarde in 
ARTIKEL. Artikelnummer. We doen dat door een referentiële integriteitsvoorwaarde 
(referential integrity constraint) op te stellen. Dat is een statement dat een beperking 
oplegt aan de waarden van een externe sleutel. We stellen in dit geval de volgende 
voorwaarde op: 


BESTELLING ITEM.Artikelnummer moet bestaan in 
ARTIKEL. Artikelnummer 
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Deze voorwaarde bepaalt dat elke waarde van Artikelnummer in BESTELLING 
ITEM overeen moet komen met een waarde van Artikelnummer in ARTIKEL. 


3.4 _Normaalvormen 


Niet alle relaties zijn hetzelfde. Sommige zijn makkelijk te verwerken, andere zijn 
problematisch. Relaties worden gecategoriseerd in normaalvormen, afhankelijk van 
het soort problemen dat ze kunnen veroorzaken. Het kennen van deze normaal- 


vormen helpt je consistente seontwerpen te maken. Voordat je de normaal- 


vormen kunt begrijpen, moeten we eerst wijziginganomalieën definiëren. 


3.4.1 Wijziginganomalieën 

Kijk eens naar de relatie REPARATIE in Figuur 3-12, die gegevens bevat over fa- 
brieksapparatuur en reparatiekosten voor die apparaten. Stel dat we de gegevens ver- 
wijderen van de reparatie met nummer 2100. Als we deze rij (de tweede rij in Figuur 
3-12) verwijderen, dan verwijderen we niet alleen gegevens over de reparatie, maar 
ook gegevens over de machine zelf. We zullen bijvoorbeeld niet meer weten dat de 
machine een draaibank is, met een aanschafprijs van € 4.750. De structuur van deze 
tabel maakt het onvermijdelijk dat we feiten verliezen over twee verschillende din- 


gen — een machine en een reparatie — als we een enkele rij verwijderen. Deze situatie 
heet een verwijderanomalie. 


Stel nu dat we de eerste keer een reparatie willen invoeren voor een bepaald appa- 
raat. We moeten niet alleen Reparatienummer, Reparatiedatum en Reparatiekosten 
kennen om reparatiegegevens te kunnen invoeren, maar ook Itemnummer, Type en 
Aanschafprijs. Dat is een probleem als we in de reparatieafdeling werken, want we 
weten de aanschafprijs dan waarschijnlijk niet. De structuur van deze tabel dwingt 


ons feiten over twee entiteiten in te voeren als we feiten over maar een daarvan wil- 
len invoeren. Dit heet een invoeganomalie. 


Stel ten slotte dat we bestaande gegevens willen wijzigen. Het wijzigen van een waar- 
de van Reparatienummer, Reparatiedatum of Reparatiekosten levert geen proble- 
men op. We kunnen echter een tegenstrijdigheid in de gegevens veroorzaken als we 
een waarde van Itemnummer, Type of Aanschafprijs wijzigen. Stel, om te demon- 
streren waarom dat zo is, dat we de laatste rij van de tabel uit Figuur 3-12 vervangen 
door de gegevens (roo, ‘Kolomboor’, 2340, 2500, ‘29-9-2010’, 275). Figuur 3-13 toont 
hoe de tabel er daarna uitziet. De kolomboor heeft twee verschillende aanschafprij- 
zen. Dat is duidelijk een fout. Hetzelfde apparaat kan niet voor twee verschillende 
prijzen worden aangeschaft. Deze fout kan echter heel moeilijk te vinden zijn als de 


tabel bijvoorbeeld 100.000 of meer rijen heeft. Deze situatie wordt een bijwerkano- 
malie genoemd. 
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REPARATIE 
Itemnummer | Type Aanschafprijs Reparatienummer | Reparatiedatum 
|___100 | Kolomboor| _ €3.500,00 2000 2-9-2010 
200 _ | praaibank| €4.750,00 | 2100 | _ 18-9-2010 € 255,00 
100 | Kolomboor| €3.500,00 | 2200 30-9-2010 € 178,00 
300 | wals | € 27.300,00 | 2300 2-9-2010 | €1.875,00 
100 | Kolomboor| €3.500,00 | 2400 24-9-2010 | € 0,00 
L___100 | kolomboor| €3.500,00 | 2500 | 29-92010 | €275,00 
Figuur 3-12 De tabel REPARATIE 
REPARATIE 
Itemnummer Type il Aanschafprijs | Reparatienummer | Reparatiedatum | Reparatiekosten 
100 Kolomboor |_ €3.500,00 | 2000 5 2-9-2010 € 375,00 
200 _ | Draaibank] c4.750,00 | 2100 |__18-9-2010 € 255,00 
100 Kolomboor |_ €3.500,00 | 2200 |__30-9-2010 | __ €178,00 
[__300 _ Wals) €27.300,00 | 2300 _2-9-2010 €1.875,00 
100___| Kolomboor| 3.500,00 | 2400 [___24-9-2010 €0,00 
100 Kolomboor[_ €2.340,00 | 2500 |___29-9-2010 € 275,00 


Figuur 3-13 De tabel REPARATIE nadat deze op een onjuiste manier is bijgewerkt 


Opmerking 

Merk op dat de tabel REPARATIE in Figuur 3-12 en Figuur 3-13 gedupliceerde gegevens bevat. De 
aanschafprijs van hetzelfde apparaat komt bijvoorbeeld meerdere keren voor. Elke tabel die dubbele 
gegevens bevat, is vatbaar voor bijwerkanomalieën zoals die in Figuur 3-13. Er wordt gezegd dat een 
tabel integriteitsproblemen (data integrity problems) heeft, als er dergelijke tegenstrijdigheden in 
voorkomen. 


3.4.2 Een korte geschiedenis van normaalvormen 

Toen Codd het relationele model definieerde, merkte hij op dat sommige tabellen 
wijziginganomalieën hadden. Hij definieerde in zijn tweede artikel? eerste, tweede 
en derde normaalvormen (of normal forms), die meestal worden genoteerd als iNF, 
2NF en 3NF. 

Hij definieerde dat elke tabel die aan de voorwaarden uit Figuur 3-4 voldoet een 
relatie in iNF is. Hij merkte verder op dat sommige tabellen in iNF wijzigingano- 
malieën hebben. Hij vond uit dat hij sommige van deze anomalieën kon verwijde- 
ren door bepaalde voorwaarden toe te passen. Er wordt gezegd dat een tabel die aan 
deze voorwaarden voldoet in 2NF is. Hij zag echter dat relaties in 2NF ook anoma- 
lieën konden hebben en hij definieerde daarom 3NF — een reeks voorwaarden die 
nog meer anomalieën verwijderen. Andere onderzoekers vonden na verloop van tijd 


2 _Codd, E.F. en A.L. Dean, (november 1971) ‘Proceedings of 1971 ACM-SIGFIDET Workshop on Data 
Description’, Access and Control, San Diego, Californië: ACM 1971. 
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nog meer manieren waarop anomalieën konden optreden, met als gevolg dat de Boy- 
ce-Codd-normaalvorm (of BCNF) werd gedefinieerd. 

Deze normaalvormen zijn zo gedefinieerd dat een relatie in BCNF in 3NF is, een 
relatie in 3NF in 2NF is en een relatie in 2NF in 1NF is. Dat wil zeggen dat een relatie 
automatisch in alle lagere vormen is als je deze in BCNF brengt. 

De normaalvormen aNEF tot en met BCNF betreffen anomalieën die veroorzaakt 
worden door functionele afhankelijkheden. Er werden later ook andere oorzaken 
van anomalieën gevonden, wat ertoe leidde dat de vierde en vijfde normaalvormen 
werden gedefinieerd (4NF en 5NF). En zo ging het maar door met onderzoekers die 
steeds meer wijziginganomalieën vonden en wegwerkten met een net weer iets be- 

tere normaalvorm dan de vorige. 

Fagin publiceerde in 1982 een artikel dat een andere richting insloeg. In plaats 
van alleen naar een volgende normaalvorm te zoeken, vroeg Fagin: ‘Onder welke 
omstandigheden heeft een relatie in het geheel geen anomalieën?’ Hij definieerde in 
dat artikel de domain key normal form, afgekort DK/NF. Fagin beëindigde de zoek- 
tocht naar normaalvormen door aan te tonen dat een relatie in DK/NF geen wijzigin- 
ganomalieën heeft en dat een relatie die geen wijziginganomalieën heeft in DK/NF 

is. DK/NF komt verderop in dit hoofdstuk aan bod. 


3.4.3 Normalisatiecategorieën 

Zoals je in Figuur 3-14 ziet, kunnen we de normalisatietheorie in drie hoofdcatego- 
rieën onderverdelen. Sommige anomalieën worden veroorzaakt door functionele af: 
hankelijkheden, sommige door meerwaardige afhankelijkheden en sommige door 
gegevensvoorwaarden en eigenaardige omstandigheden. 

BCNF, 3NF en 2NF houden zich allemaal bezig met door functionele afhankelijk- 
heden veroorzaakte anomalieën. Een relatie die in BCNF is, heeft geen door functi- 
onele afhankelijkheden veroorzaakte wijziginganomalieën en is automatisch in 2NF 
en 3NF. We gaan daarom niet verder op 2NF en 3NF in. Zie Date“ als je de definities 
hiervan wilt zien. We concentreren ons op het omzetten van relaties naar BCNF. 

Zoals je in de tweede rij van Figuur 3-14 ziet, worden sommige anomalieën ver- 
oorzaakt door een ander soort afhankelijkheid, die een meerwaardige afhankelijk- 
heid wordt genoemd. Deze anomalieën zijn te elimineren door elke meerwaardige 
afhankelijkheid in een eigen relatie op te nemen. Deze toestand noemen we 4NF. Je 
ziet in het laatste deel van dit hoofdstuk hoe je dat doet. 

De derde bron van anomalieën is nogal vergezocht. Ze hebben te maken met on- 


gewone en soms zelfs vreemde voorwaarden die aan de gegevens worden gesteld. 
We zullen ze daarom hier niet bespreken. 


3 _R. Fagin, (September 1981) ‘A Normal Form for Relational Databases that Is Based on Domains and 
Keys’, ACM Transactions on Database Systems, pagina 387-414. 
4 C.J. Date (2003) Database Systems, 8“* editie Addison-Wesley. 
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Bron van anomalie [Normaalvormen Ontwerpprincipes 
Functionele afhankelijkheden INE 2NF 3NF, BCNF p BCNF: ontwerp elke tabel zo 
dat elke determinant een 
if | kandidaatsleutel is. 
Meerwaardige afhankelijkheden 5 ANF ANF: verplaats elke meerwaardige 
afhankelijkheid naar een eigen 
tabel. 
Gegevensvoorwaarden en SNE, DK/NF DK/NF: maak elke 
eigenaardige omstandigheden randvoorwaarde tot een logisch 
gevolg van kandidaatsleutels en 
| domeinen. 


Figuur 3-14 Normalisatie categorieën 


3.4.4 Door functionele afhankelijkheden veroorzaakte anomalieën 
elimineren 

De meeste wijziginganomalieën treden op door problemen die worden veroorzaakt 

door functionele afhankelijkheden. Je kunt dergelijke problemen elimineren door 

de tabellen zo te (her)ontwerpen dat elke determinant een kandidaatsleutel is. Deze 

toestand — die de definitie van BCNF is — zal alle door functionele afhankelijkheden 

veroorzaakte anomalieën elimineren. 

De algemene strategie is samengevat in Figuur 3-15. Identificeer elke functionele 
afhankelijkheid in de relatie. Identificeer kandidaatsleutels. Zijn er determinanten 
die geen kandidaatsleutels zijn, dan is de relatie niet in BCNF en zal deze wijzigin- 
ganomalieën hebben. Je brengt de relatie in BCNF door de in stap 3 beschreven pro- 
cedure te volgen. Deze procedure is zo belangrijk dat we deze aan de hand van vijf 
verschillende voorbeelden toelichten. 


Procedure voor het in BCNF brengen van een relatie 
1. Identificeer elke functionele afhankelijkheid. 
2. Identificeer elke kandidaatsleutel. 
3. Is er een functionele afhankelijkheid die een determinant heeft die geen kandidaatsleutel is, doe dan het 
volgende: : 
3a. | Verplaats de kolommen van deze functionele afhankelijkheid naar een nieuwe relatie. 
3b. | Maak de determinant van deze functionele afhankelijkheid tot de primaire sleutel van de nieuwe 


relatie. Ee 
3C. Laat een kopie van de determinant in de originele relatie staan als een externe sleutel. 


3d. | Maak een referentiële integriteitsvoorwaarde die de originele en de nieuwe relatie aan elkaar 
koppelt. 
4. Herhaal stap 3 tot elke determinant van elke relatie een kandidaatsleutel is. 
Opmerking: zijn er in stap 3 meer van dergelijke functionele afhankelijkheden, dan begin je met die welke 
de meeste kolommen heeft. 
Figuur 3-15 De procedure voor het in BCNF brengen van een relatie 


97 


T 
& 


DEEL? | DATABASES ONTWERPEN 


3.4.5 Normalisatie: voorbeeld 1 
Kijk eens naar de tabel ARTIKEL: 


ARTIKEL (Artikelnummer, Artikelomschrijving, Afdeling, Inkoper) 
Deze tabel heeft, zoals al eerder besproken, drie functionele afhankelijkheden: 


Artikelnummer — (Artikelomschrijving, Afdeling, Inkoper) 
Artikelomschrijving > (Artikelnummer, Afdeling, Inkoper) 
Inkoper — Afdeling 


Artikelnummer en Artikelomschrijving bepalen alle kolommen van de tabel en zijn 
dus kandidaatsleutels. Inkoper is een determinant van Afdeling, maar bepaalt geen 
van de andere kolommen en is dus geen kandidaatsleutel. ARTIKEL heeft dus een 
determinant die geen kandidaatsleutel is en is dus niet in BCNF. Deze tabel zal wij- 
zìiginganomalieën hebben. 

Stap 3a beschrijft hoe we dergelijke anomalieën elimineren, door de kolommen 
van een functionele afhankelijkheid waarvan de determinant geen kandidaatsleutel 


is naar een nieuwe tabel te verplaatsen. We plaatsen in dit geval Inkoper en Afdeling 
in een nieuwe tabel: 


INKOPER (Inkoper, Afdeling) 


We maken daarna de determinant van de functionele afhankelijkheid tot de primaire 


sleutel van de nieuwe tabel (stap 3b). Dat betekent in dit geval dat Inkoper de pri- 
maire sleutel wordt: 


INKOPER (Inkoper, Afdeling) 


We volgen daarna stap 3c en laten een kopie van de determinant in de originele 
relatie staan als een externe sleutel. ARTIKEL wordt dus: 


ARTIKEL2 (Artikelnummer, Artikelomschrijving, Inkoper) 


De resulterende tabellen zijn dus: 


ARTIKEL2 (Artikelnummer, Artikelomschrijving, Inkoper) 
INKOPER (Inkoper, Afdeling) 


Hierbij is ARTIKEL2. Inkoper een externe sleutel naar de tabel INKOPER. 

Deze tabellen zijn nu beide in BCNF en zullen geen door functionele afhanke- 
lijkheden veroorzaakte anomalieën hebben. We moeten in stap 3d echter nog een 
referentiële integriteitsvoorwaarde definiëren om zeker te stellen dat de gegevens in 
deze tabellen consequent met elkaar overeenkomen: 


HET RELATIONELE MODEL EN NORMALISATIE 


ARTIKEL2. Inkoper moet bestaan in INKOPER. Inkoper 


Dit statement betekent dat elke waarde in de kolom Inkoper van ARTIKEL2 ook 
moet bestaan als een waarde in de kolom Inkoper van INKOPER. Je ziet voorbeeld- 
gegevens uit de resulterende tabellen in Figuur 3-16. 


INKOPER 8 
Inkoper _| Afdeling 
Charlotte Laan | Camping 
Marc Appels | Klimmen | 
Najma Barends __| Watersport 
[Peter Jansen | Watersport | 
ARTIKEL2 
Artikelnummer | Artikelomschrijving |: Inkoper 
L 100100 Standaard SCUBA, geel Peter Jansen 
_ 100200 _Í standaard SCUBA, magenta Peter Jansen 
__101100 Ouikmasker, small, helder al Najma Barends 
101200 Ouikmasker, medium, helder Najma Barends 
[ 201000 Halvekoepeltent e R Charlotte Laan | 
202000 | Grondzeil halvekoepeltent Charlotte Laan 
_____301000 __{ Lichtgewicht klimharnas Marc Appels 
302000 | Karabijnsluiting, ovaal É, [Marc Appels | 


Figuur 3-16 Voorbeeldgegevens voor de relaties ARTIKEL2 en INKOPER 


3.4.6 Normalisatie: voorbeeld 2 
Kijk nu eens naar de relatie REPARATIE in Figuur 3-17. 


REPARATIE 
Itemnummer Type Aanschafprijs | Reparatienummer | Reparatiedatum 
[7 05 Kolomboor |__€ 3.500,00 2000 2-9-2010 € 375,00 
___200 | Draaibank| €4.750,00 2100 18-9-2010 € 255,00 
100___|_Kolomboor |__ € 3.500,00 2200 30-9-2010 
Bode wals |_€ 27.300,00 2300 2-9-2010 
100 | Kolomboor| €3.500,00 | 2400 24-9-2010 
100 |_Kolomboor| €3.500,00 | 2500 29-9-2010 


Figuur 3-17 De tabel REPARATIE 
De structuur van deze tabel is: 


REPARATIE (Itemnummer, Type, Aanschafprijs, Reparatienummer, 
Reparatiedatum, Reparatiekosten) 


Als we de gegevens in Figuur 3-17 bekijken, zijn de functionele afhankelijkheden: 
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Itemnummer —» (Type, Aanschafprijs) 
| Reparatienummer — (Itemnummer, Type, Aanschafprijs, 
ie Reparatiedatum, Reparatiekosten) 


Itemnummer en Reparatienummer zijn beide determinanten, maar alleen Repara- 
tienummer is een kandidaatsleutel. REPARATIE is dus niet in BCNF en is dus vat- 
ik baar voor wijziginganomalieën. We volgen de procedure uit Figuur 3-15 en plaatsen 
de kolommen van de problematische functionele afhankelijkheid als volgt in een 
afzonderlijke tabel: 
ITEM (Itemnummer, Type, Aanschafprijs) 


We verwijderen al deze kolommen, behalve Itemnummer, uit REPARATIE en 
maken: 


REPARATIE? (Itemnummer, Reparatienummer, Reparatiedatum, 
Reparatiekosten) 


We moeten nu nog de referentiële integriteitsvoorwaarde maken: 
REPARATIE2. Itemnummer moet bestaan in ITEM. Itemnummer 


Je ziet voorbeeldgegevens voor deze twee nieuwe relaties in Figuur 3-18. 


Aanschafprijs 


€ 3.500,00 
€ 4.750,00 
€ 27.300,00 


|_Reparatienummer | itemnummer | Reparatiedatum |_Reparatiekosten | 
100 2-9-2010 | € 375,00 
30-9-2010 € 178,00 
24-9-2010 
29-9-2010 
18-9-2010 € 255,00 


2-9-2010 € 1.875,00 


Figuur 3-18 Voorbeeldgegevens voor de relaties REPARATIE2 en ITEM 


3.4.7 Normalisatie: voorbeeld 3 
Kijk eens naar de relatie BESTELLING ITEM met de structuur: 
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HET RELATIONELE MODEL EN NORMALISATIE 


BESTELLING ITEM (Bestellingnummer, Artikelnummer, Aantal, 
Stukprijs, Totaalprijs) 


Deze relatie heeft de volgende functionele afhankelijkheden: 


(Bestellingnummer, Artikelnummer) — (Aantal, Stukprijs, 
Totaalprijs) 
(Aantal, Stukprijs) — Totaalprijs 


Deze tabel is niet in BCNEF, want de determinant (Aantal, Stukprijs) is geen kandi- 
daatsleutel. We zouden dezelfde werkwijze voor het normaliseren kunnen gebrui- 
ken als in voorbeeld 1 en 2, maar dat levert een onzinnig resultaat op, omdat de 
tweede functionele afhankelijkheid wordt veroorzaakt door de formule Totaalprijs = 
Aantal * Stukprijs. 

We kunnen demonstreren waarom dat zo is door de procedure uit Figuur 3-15 te 
volgen en nieuwe tabellen te maken, zodat elke determinant een kandidaatsleutel is. 
Dat betekent dat we de kolommen Aantal, Stukprijs en Totaalprijs als volgt naar ei- 
gen tabellen moeten verplaatsen: 


TOTAALPRIJS (Aantal, Stukprijs, Totaalprijs) 
BESTELLING ITEM (Bestellingnummer, Artikelnummer, Aantal, 
Stukprijs) 


Merk op dat we Aantal en Stukprijs beide in de originele relatie lieten staan als een 
samengestelde externe sleutel. Deze twee tabellen zijn in BCNF, maar de waarden 
in de tabel TOTAALPRIJS zijn nog niet optimaal. Dat zijn gewoon de resultaten van 
het vermenigvuldigen van Aantal en Stukprijs. We hoeven geen tabel te maken om 
die resultaten op te slaan. We kunnen Totaalprijs in plaats daarvan gewoon elke keer 
berekenen als we deze waarde nodig hebben. We kunnen deze formule in feite voor 
het DBMS definiëren en de waarde van Totaalprijs waar nodig door het DBMS laten 
berekenen. 

We kunnen Totaalprijs uit de tabel verwijderen als we de formule gebruiken. De 


resulterende tabel is in BCNF: 


BESTELLING ITEM (Bestellingnummer, Artikelnummer, Aantal, 
Stukprijs) 


Merk op dat Aantal en Stukprijs geen externe sleutels meer zijn. De tabel ziet er met 
wat gegevens nu uit als in Figuur 3-19. 
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MEE 000 201000 1_ | €300,00 
en 
EE 20 101100 4 €50,00 | 


Figuur 3-19 De tabel BESTELLING ITEM 


3.4.8 Normalisatie: voorbeeld 4 
Kijkeens naar de volgende tabel, die gegevens opslaat over activiteiten voor studenten: 


STUDENTENACTIVITEIT (SID, Naam, Club, Kosten, Betaald) 


SID is hier een identificatienummer van een student, Naam is de naam van de stu- 
dent, Club is de naam van een club, Kosten geeft aan hoeveel het kost om lid te wor- 
den van een club en Betaald geeft aan hoeveel de student aan deze club heeft betaald. 
Figuur 3-20 toont voorbeeldgegevens voor deze tabel. 


STUDENTENACTIVITEIT 
€0,00 | 


Duiken | € 400,00 € 400,00 
Oud Skiën| €550,00 | €550,00 
a | 300 | Gerritsl_ Klimmenl c150,00 | €150,00 
5 | 4oo [__ jong] Skiën| €550,00 | c 550,00 


Figuur 3-20 Voorbeeldgegevens voor de relatie STUDENTENACTIVITEIT 


SID is een uniek identificatienummer voor een student en we weten dus dat SID 
> Naam. Maar geldt ook dat SID > Club? Dat is het geval als elke student lid is van 
maar één club, maar niet als er studenten zijn die lid zijn van meer clubs. We zien in 
de voorbeeldgegevens dat student 200 lid is van twee verschillende clubs. Club wordt 
dus niet door SID bepaald. Kosten en Betaald worden ook niet door SID bepaald. 
Kijk nu eens naar de kolom Naam. Wordt SID bepaald door Naam? Is de waar- 
de ‘Jong’ bijvoorbeeld altijd aan dezelfde waarde van SID gekoppeld? Nee, want er 
zijn twee studenten met de naam Jong en deze hebben verschillende SID-waarden. 
Naam bepaalt ook geen van de andere kolommen in deze tabel. Als we doorgaan 
naar de volgende kolom, Club, dan weten we dat veel studenten lid kunnen zijn van 
een club. Dat betekent dat SID en Naam niet door Club worden bepaald. Wordt Kos- 
ten door Club bepaald? Is de waarde van ‘Duiken’ bijvoorbeeld altijd aan dezelfde 
waarde van Kosten gekoppeld? Dat lijkt op basis van deze gegevens het geval te zijn. 
Als we alleen van de voorbeeldgegevens uitgaan, kunnen we concluderen dat Club 
Kosten bepaalt. 
Deze gegevens zijn echter alleen een voorbeeld. Logisch gezien is het mogelijk dat 
studenten verschillende kosten betalen — bijvoorbeeld doordat ze voor verschillende 
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lidmaatschappen kiezen. Zou dat het geval zijn, dan zouden we zeggen dat (SID, 
Club) ” Kosten. We moeten dat uitzoeken door met de gebruikers te praten. Laten 
we er in dit geval van uitgaan dat alle studenten dezelfde kosten betalen voor een be- 
paalde club. De laatste kolom is Betaald en deze bepaalt niets. 

We hebben tot dusver twee functionele afhankelijkheden: 


SID — Naam 
Club — Kosten 


Zijn er nog andere functionele afhankelijkheden met samengestelde determinan- 
ten? Betaald wordt door geen enkele afzonderlijke kolom bepaald. Laten we dus eens 
kijken of er misschien samengestelde determinanten voor zijn. Het betaalde bedrag 
is zowel afhankelijk van de student als van de club waarvan de student lid is gewor- 
den. Betaald wordt dus bepaald door de combinatie van de determinanten SID en 
Club. We kunnen dus zeggen: 


(SID, Club) — Betaald 


We hebben tot dusver drie determinanten: SID, Club en (SID, Club). Zijn sommige 
daarvan ook kandidaatsleutels? [dentificeren sommige ervan een unieke rij? Het lijkt 
op basis van deze gegevens dat (SID, Club) een unieke rij identificeert en een kandi- 
daatsleutel is. We zouden deze aanname in de praktijk ook weer moeten controleren 
door met de gebruikers te praten. 

STUDENTENACTIVITEIT is niet in BCNF, want de kolommen SID en Club zijn 
beide determinanten, maar ze zijn geen van beide een kandidaatsleutel. Ze maken 
beide alleen maar deel uit van de kandidaatsleutel (SID, Club). 


Opmerking 
SID en Club maken beide deel vit van de kandidaatsleutel (SID, Club). Dat is echter niet voldoende. Een 
determinant moet a/fe kolommen van een tabel omvatten om een kandidaatsleutel te zijn. 


We moeten nieuwe tabellen maken, zodat elke determinant een kandidaatsleutel is, 
als we deze tabel willen normaliseren. We kunnen dat op dezelfde manier doen als 
dat we al eerder deden: door een afzonderlijke tabel te maken voor elke functionele 
afhankelijkheid. Het resultaat is: 


STUDENT (SID, Naam) 
CLUB (Club, Kosten) 
BETALING (SID, Club, Betaald) 


met de volgende referentiële integriteitsvoorwaarden: 


BETALING.SID moet bestaan in STUDENT.SID 
en 
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BETALING.Club moet bestaan in CLUB.Club 


Deze tabellen zijn in BCNF en zullen geen door functionele afhankelijkheden ver- 


oorzaakte anomalieën hebben. Je ziet de voorbeeldgegevens voor de genormaliseer- 
de tabellen in Figuur 3-21. 


BETE 
sio | Naam | 


Lsoo |jong | 


Weer| 


100 | Duiken € 0,00 
200 [Duiken _| €400,00 
200 skien | cssooo | 
300 
Loo [sken___ | cssooo | 


Figuur 3-21 Voorbeeldgegevens voor de relaties STUDENT, CLUB en BETALING 


3.4.9 Normalisatie: voorbeeld 5 


Laten we nu eens een normalisatieproces bekijken waarvoor we stap 3 van de in 
Figuur 3-15 getoonde procedure tweemaal moeten doorlopen. We doen dat door de 
relatie ARTIKEL uit te breiden door de budgetcode van elke afdeling toe te voegen: 


ARTIKEL3 (Artikelnummer, Artikelomschrijving, Afdeling, 
Afdelingsbudgetcode, Inkoper) 


Je ziet voorbeeldgegevens voor deze relatie in Figuur 3-22. 
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ARTIKEL3 
Artikel- Artikelomschrijving Afdeling Afdelings- 
nummer | budgetcode 


100100 Standaard SCUBA, geel | watersport | BC-100 Peter Jansen 

100200 _ | standaard SCUBA, magenta | Watersport | 8C-100 Peter Jansen 

101100 _ | Duikmasker, small, helder Watersport | BCG100 najm Barends 7 
101200 _ | Duikmasker, medium, helder | Watersport | BC-100 Najma Barends 

|__201000 | Halvekoepeltent | Camping a BC-200 | charlotte Laan 

202000 _ | Grondzeil halvekoepeltent _ | Camping | __BC200 Charlotte Laan J 
301000 _ | Lichtgewicht klimharnas Klimmen | BC-300 [marc Appels 

302000 _ | Karabijnsluiting, ovaal Klimmen BC-300 Marc Appels 


Figuur 3-22 Voorbeeldgegevens voor de relatie ARTIKEL3 


ARTIKEL3 heeft de volgende functionele afhankelijkheden: 


Artikelnummer — (Artikelomschrijving, Afdeling, 
Afdelingsbudgetcode, Inkoper) 
Artikelomschrijving — (Artikelnummer, Afdeling, 
Afdelingsbudgetcode, Inkoper) 
Inkoper — (Afdeling, Afdelingsbudgetcode) 
Afdeling > Afdelingsbudgetcode 


Twee van de vier determinanten, Artikelnummer en Artikelomschrijving, zijn kan- 
didaatsleutels. Afdeling en Inkoper zijn echter geen van beide kandidaatsleutels en 
deze relatie is dus niet in BCNF. 

We moeten deze tabel in twee of meer tabellen omzetten die in BCNF zijn, als 
we deze willen normaliseren. Er zijn in dit geval twee functionele afhankelijkheden 
die problemen veroorzaken. We houden ons aan de opmerking aan het einde van de 
procedure in Figuur 3-15 en beginnen met de functionele afhankelijkheid met het 
grootste aantal kolommen. We nemen in dit geval de kolommen van: 


Inkoper — (Afdeling, Afdelingsbudgetcode) 

en nemen deze op in een eigen tabel. 
We maken daarna de determinant tot de primaire sleutel van de nieuwe tabel, verwij- 
deren al deze kolommen behalve Inkoper uit ARTIKEL3 en maken Inkoper tot een 


externe sleutel in de nieuwe versie van ARTIKEL3. Het resultaat is: 


INKOPER (Inkoper, Afdeling, Afdelingsbudgetcode) 
ARTIKEL4 (Artikelnummer, Artikelomschrijving, Inkoper) 


We stellen verder de volgende referentiële integriteitsvoorwaarde op: 
ARTIKEL4.Inkoper moet bestaan in INKOPER. Inkoper 
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De functionele afhankelijkheden van ARTIKEL4 zijn: 


Ì Ge Artikelnummer > (Artikelomschrijving, Inkoper) 
bd: Artikelomschrijving > (Artikelnummer, Inkoper) 


en de functionele afhankelijkheden van INKOPER zijn: 


Inkoper — (Afdeling, Afdelingsbudgetcode) 
Afdeling > Afdelingsbudgetcode 


INKOPER is niet in BCNF, want Afdeling is een determinant die geen kandidaat- 
sleutel is. We moeten (Afdeling, Afdelingsbudgetcode) daarom naar een eigen tabel 


verplaatsen. We volgen daartoe opnieuw de procedure uit Figuur 3-15 en krijgen nu: 


INKOPER2 (Inkoper, Afdeling) 
AFDELING (Afdeling, Afdelingsbudgetcode) 


en 
ARTIKEL4 (Artikelnummer, Artikelomschrijving, Inkoper) 
met de referentiële integriteitsvoorwaarden: 


ARTIKEL4. Inkoper moet bestaan in INKOPER2. Inkoper 
INKOPER2.Afdeling moet bestaan in AFDELING. Afdeling 


De functionele afhankelijkheden van deze tabellen zijn: 


Inkoper — Afdeling 

Afdeling — Afdelingsbudgetcode 

Artikelnummer > (Artikelomschrijving, Inkoper) 
Artikelomschrijving — Artikelnummer, Inkoper 


Elke determinant is nu eindelijk een kandidaatsleutel en alle drie de tabellen zijn in 
BCNF. Je ziet het resultaat van deze bewerkingen in Figuur 3-23. 


Afdeling Afdelingsbudgetcode 


Camping BC-200 


BC-300 
Watersport 


BC-100 
Figuur 3-23 Voorbeeldgegevens voor de relaties INKOPER2, AFDELING en ARTIKEL4 
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INKOPER2 


Inkoper Afdeling 
| charlotte Laan | camping 
Johan Martens | Klimmen 
Najma Barends | watersport el 
Peter Jansen Watersport : 
ARTIKEL4 ä 
[_ Artikelnummer Artikelomschrijving Inkoper 
Ae 100100 Standaard SCUBA, geel Peter Jansen 
100200 Standaard SCUBA, magenta Peter Jansen 
| 101100 | Duikmasker, small, helder Najma Barends 
101200 Duikmasker, medium, helder Najma Barends 
201000 Halvekoepeltent Charlotte Laan 
202000 Grondzeil halvekoepeltent Charlotte Laan. | 
| 301000 Lichtgewicht klimharnas Johan Martens 
| 302000 |Karabijnsluiting, ovaal inn Martens 


Figuur 3-23 (vervolg) 


3.5 Door meerwaardige afhankelijkheden veroorzaakte 
anomalieën elimineren 


Alle anomalieën uit de vorige paragraaf werden veroorzaakt door functionele af- 
hankelijkheden. Er is nog een ander soort van afhankelijkheid, de meerwaardige 
afhankelijkheid, die ook tot anomalieën kan leiden. Er treedt een meerwaardige af- 
hankelijkheid op als een determinant aan een bepaalde verzameling waarden is ge- 
koppeld. Voorbeelden van meerwaardige afhankelijkheden zijn: 


Werknemer — > Diploma 
Werknemer — > Familieleden 
Onderdelenkit — — Onderdeel 


De meervoudige determinanten worden met een dubbele in plaats van een enkele 
pijl weergegeven. Dergelijke expressies worden gelezen als “Werknemer bepaalt Di- 
ploma meervoudig’ en ‘Werknemer bepaalt Familieleden meervoudig’. 

De determinant is in elk van deze gevallen aan een verzameling waarden gekop- 
peld. Je ziet voorbeeldgegevens voor elk van deze meervoudige afhankelijkheden in 
Figuur 3-24. 

Werknemer Jansen heeft twee diploma’s, werknemer Groen heeft drie diploma’s 
en werknemer Cho heeft er slechts een. 

Werknemer Jansen heeft de familieleden (broers en zussen) Fred, Ellie en Frank. 
Werknemer Groen heeft het familielid Nikki en werknemer Cho heeft de familie- 
leden Jan en Erica. 
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WERKNEMER_DIPLOMA 


WERKNEMER _FAMILIELEDEN 


Diploma Werknemer Familieleden 
[jan 
| Erica 
| Nikki 
Jansen | Frank 
| jansen | Fred 
|jansen | Ellie | 


ONDERDELENKIT ONDERDEEL 
Onderdelenkit Onderdeel 
Fietsreparatie Moersleutel 
Bandreparatieset 
Fietsreparatie Schroevendraaier 
[gankschroef {hendel | 


Eerste hulp Aspirine 
Eerste hulp Verband 


Figuur 3-24 Drie voorbeelden van meervoudige afhankelijkheden 


De Onderdelenkit voor Fietsreparatie bestaat uit de onderdelen Moersleutel, Schroe- 


vendraaier en Bandreparatieset. Andere onderdelenkits hebben de in Figuur 3-24 
getoonde onderdelen. 


De determinant van een meervoudige afhankelijkheid kan, anders dan bij functio- 
nele afhankelijkheden, nooit de primaire sleutel zijn. De primaire sleutel bestaat bij 
alle drie de tabellen uit Figuur 3-24 uit de samenstelling van de beide kolommen van 
de tabel. De tabel WERKNEMER _DIPLOMA heeft de primaire sleutel (Werknemer, 
Diploma). 

Meerwaardige afhankelijkheden vormen geen probleem, zolang ze maar in eigen 
tabellen staan. De tabellen in Figuur 3-24 hebben geen van alle wijziginganomalie- 
en. Maar als een relatie met A + — B een of meer andere kolommen bevat, zal zij wel 
wijziginganomalieën hebben. 

Kijk bijvoorbeeld eens wat er gebeurt als we de werknemergegevens uit Figuur 
3-24 combineren tot een enkele tabel met drie kolommen: Werknemer, Diploma en 
Familieleden. Je ziet dat in Figuur 3-25. 

Welke acties zijn er nu nodig als student Jansen een MBA-diploma haalt? We 
moeten dan drie rijen aan de tabel toevoegen. Doen we dat niet, en voegen we bij- 
voorbeeld alleen de rij Jansen’, ‘MBA:, ‘Frank’) toe, dan lijkt het of Jansen wel een 


MBA-diploma heeft samen met haar broer Frank, maar niet samen met haar broer 
Fred of met haar zus Ellie. 
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WERKNEMER _ FAMILIELEDEN 
Werknemer Diploma Familieleden 
Cho |BS Jan ed 
Cho BS Erica 
‚Groen BS ÍNikki 
Groen MS Nikki 
Groen PhD Nikki 
|Jansen LAA | Frank 
Jansen [BS Frank 
| jansen |AA Fred 
Jansen BS Fred 
Jansen AA Ellie 
T 
[Jansen | BS Ellie 


Figuur 3-25 Een relatie met twee meerwaardige afhankelijkheden 


Maar wat gebeurt er als Groen een MBA-diploma haalt? We moeten dan alleen de 
enkele rij (‘Groen’, ‘MBA’, ‘Nikkt') toevoegen. En we moeten twee rijen toevoegen als 
Cho een MBA-diploma haalt. Dat zijn invoeganomalieën. Er zijn ook overeenkom- 
stige wijziging- en verwijderanomalieën. 

We combineerden in Figuur 3-25 de twee meerwaardige afhankelijkheden in een 
enkele tabel en kregen wijziginganomalieën. We krijgen jammer genoeg ook ano- 
malieën als we een meerwaardige afhankelijkheid met een willekeurige andere ko- 
lom combineren — zelfs als die andere kolom geen meerwaardige afhankelijkheid 
heeft. 

Je begrijpt nu ook wat er gebeurt als we de meerwaardige afhankelijkheid Onder- 
delenkit combineren met de functionele afhankelijkheid Onderdelenkit > Prijs. We 
moeten de waarde voor de prijs in elke rij met een onderdeel van een kit herhalen, 
willen de gegevens consequent zijn. We moeten bijvoorbeeld drie rijen toevoegen 
voor de kit Fietsreparatie en vier rijen voor de kit Eerste hulp. Dat resulteert in ge- 
dupliceerde gegevens die problemen kunnen veroorzaken met de integriteit van de 
gegevens. 

Je begrijpt nu ook wat het probleem is met de relatie in Figuur 3-2 uit het begin 
van dit hoofdstuk. Er komen anomalieën voor in deze tabel omdat Inkoper > > Arti- 
kelnummer en Inkoper > > Hoofdvak. Meerwaardige afhankelijkheden zijn geluk- 
kig makkelijk te verhelpen: je moet ze alleen naar een eigen tabel verplaatsen. De 
tabellen in Figuur 3-24 hebben geen van alle wijziginganomalieën, want elk van deze 
tabellen bestaat alleen uit de kolommen van een enkele meerwaardige afhankelijk- 
heid. Willen we de problemen met de tabel in Figuur 3-2 verhelpen, dan moeten we 
Inkoper en Artikelnummer dus naar een nieuwe, eigen tabel verplaatsen en Inkoper 
en Hoofdvak naar een tweede nieuwe tabel: 


INKOPER ARTIKELNUMMER (Inkoper, Artikelnummer) 
INKOPER HOOFDVAK (Inkoper, Hoofdvak) 


Je ziet het resultaat in Figuur 3-26. 
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inkoper je Artikelnummer 
101100 
101200 


INKOPER _HOOFDVAK 


Inkoper Hoofdvak 
Najma Barends Kunstgeschiedenis 
Najma Barends Informatiesystemen 
Peter Jansen Bedrijfskunde 
Figuur 3-26 Twee van de meerwaardige afhankelijkheden uit Figuur 3-2 naar afzonderlijke relaties verplaatsen 


Willen we een strikte overeenkomst tussen deze tabellen behouden, dan moeten we 
ook de volgende referentiële integriteitsvoorwaarde toevoegen: 


INKOPER ARTIKELNUMMER. Inkoper moet identiek zijn aan 
INKOPER _HOOFDVAK. Inkoper 


Deze referentiële integriteitsvoorwaarde zal misschien niet nodig zijn — dat is afhan- 
kelijk van de eisen van de toepassing. 

Merk op dat meerwaardige afhankelijkheden verdwijnen als je ze naar een eigen 
tabel verplaatst. Het resultaat is een gewone tabel met twee kolommen, waarbij de 
primaire sleutel (en de enige kandidaatsleutel) uit de samenstelling van deze beide 
kolommen bestaat. Zijn de meervoudige afhankelijkheden op deze manier geïso- 
leerd, dan wordt er gezegd dat de tabel in de vierde normaalvorm (4NF) is. 

Het grootste probleem van meerwaardige afhankelijkheden is deze te vinden. Als 
je ze eenmaal gevonden hebt, dan kun je ze gewoon naar een eigen tabel verplaat- 
sen. Zoek altijd naar meerwaardige afhankelijkheden als je tabellen tegenkomt met 
vreemde anomalieën — vooral als die anomalieën je ertoe dwingen verschillende aan- 
tallen rijen in te voegen, te wijzigen of te verwijderen om de integriteit te behouden. 


Opmerking 

Je hoort soms dat mensen het woord normaliseren gebruiken in zinnen zoals ‘die tabel is 
genormaliseerd’, of ‘controleer of deze tabellen genormaliseerd zijn’. Sommige mensen kennen BCNF 
niet en zullen hiermee bedoelen dat tabellen in 3NF zijn. Anderen bedoelen hiermee dat tabellen zowel 
in BCNF als in 4NF zijn. Weer anderen bedoelen misschien nog iets anders. Het beste is het de term 
genormaliseerd te gebruiken voor tabellen die zowel in BCNF als in 4NF zijn. 


Samenvatting 


Databases kunnen op drie manieren ontstaan: op basis van bestaande gegevens, bij 
het ontwikkelen van nieuwe systemen en door het herontwerpen van bestaande da- 
tabases. Dit en het volgende hoofdstuk behandelen databases die ontstaan vanuit 
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bestaande gegevens. Dit hoofdstuk licht de normalisatie toe om deze dataproblemen 
te begrijpen en op te lossen. Figuur 3-3 toont een lijst met termen waarmee je bekend 
moet zijn. 

Een relatie is een speciaal geval van een tabel — alle relaties zijn tabellen, maar 
niet alle tabellen zijn relaties. Relaties zijn tabellen die de kenmerken uit Figuur 3-4 
hebben. Er worden drie reeksen termen gebruikt voor het beschrijven van de relatie- 
structuur: (relatie, attribuut, tupel), (tabel, kolom, rij) en (bestand, veld, record). Deze 
termen worden soms door elkaar gebruikt. De termen tabel en relatie worden in de 
praktijk gebruikt als synoniemen en we gebruiken ze in de rest van dit boek ook zo. 

In een functionele afhankelijkheid wordt de waarde van het ene attribuut bepaald 
door de waarde, of waarden, van een of meer andere attributen. Attribuut A in de 
functionele afhankelijkheid A > B noemen we de determinant. Sommige functione- 
le afhankelijkheden zijn het resultaat van vergelijkingen, maar dat is lang niet altijd 
het geval. Databases hebben feitelijk tot doel instanties van functionele afhankelijk- 
heden op te slaan die niet worden veroorzaakt door vergelijkingen. Determinanten 
die meer dan één attribuut hebben, noemen we samengestelde determinanten. Als 
A > (B, C), dan A > B en A > C. Als echter (A, B) > C, dan geldt over het algemeen 
noch A > C, noch B > C. 

Als A > B, dan kunnen de waarden van A al dan niet uniek zijn in een relatie. Een 
gegeven waarde van A zal echter altijd en overal in de tabel aan dezelfde waarde van 
B zijn gekoppeld. Een determinant is alleen uniek in een relatie als deze elk ander 
attribuut van de relatie bepaalt. Je kunt er niet altijd op vertrouwen dat functionele 
afhankelijkheden zijn te bepalen op basis van voorbeeldgegevens. Je kunt de conclu- 
sies het beste verifiëren door met de gebruikers van de gegevens te spreken. 

Een sleutel is een combinatie van een of meer kolommen die wordt gebruikt voor 
het identificeren van een of meer rijen. Een samengestelde sleutel is een sleutel met 
twee of meer attributen. Een determinant die elk ander attribuut bepaalt, noemen 
we een kandidaatsleutel. Een relatie kan meer dan één kandidaatsleutel hebben. Een 
daarvan wordt geselecteerd om het DBMS te laten zoeken naar rijen. Deze noemen 
we de primaire sleutel. Een surrogaatsleutel is een kunstmatig attribuut dat als een 
primaire sleutel wordt gebruikt. De waarde van een surrogaatsleutel wordt door het 
DBMS geleverd en is meestal van geen betekenis voor de eindgebruiker. Een externe 
sleutel is een sleutel in een tabel die naar de primaire sleutel van een andere tabel 
verwijst. Een referentiële integriteitsvoorwaarde is een aan de gegevenswaarden van 
een externe sleutel opgelegde beperking die garandeert dat elke waarde van de ex- 
terne sleutel overeenkomt met een waarde van een primaire sleutel. 

De drie soorten wijziginganomalieën zijn invoeg-, bijwerk- en verwijderano- 
malieën. Codd en anderen hebben normaalvormen gedefinieerd die allerlei tabel- 
structuren beschrijven die tot anomalieën leiden. Sommige anomalieën worden 
veroorzaakt door functionele afhankelijkheden. De drie normaalvormen 2NF, 3NF 
en BCNF worden gebruikt voor het verwijderen van dergelijke anomalieën. We hou- 
den ons in dit boek alleen met BCNF bezig. Er kunnen geen door functionele afhan- 
kelijkheden veroorzaakte anomalieën optreden als een relatie in BCNF is. Een relatie 
is in BCNF als elke determinant een kandidaatsleutel is. 
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Sommige anomalieën worden veroorzaakt door meerwaardige afhankelijkheden. 
B wordt meervoudig bepaald door A, of A > > B, als A een verzameling waarden 
bepaalt. Elke relatie die A, B en een of meer andere kolommen bevat, zal wijzigin: 
ganomalieën hebben als B meervoudig wordt bepaald door A. Uit meerwaardige af- 
hankelijkheden resulterende anomalieën zijn te elimineren door de meerwaardige 
afhankelijkheid naar een eigen tabel te verplaatsen. Zulke tabellen zijn in 4NF. 


Belangrijke termen 


attribuut 
bijwerkanomalie 
Boyce-Codd-normaalvorm (BCNF) 
derde normaalvorm (3NF) 
determinant 

domain key normal form (DK/NF) 
eerste normaalvorm (1NF) 

entity 

externe sleutel 

foreign key 

functioneel afhankelijk 

gegevensintegriteit 

invoeganomalie 

kandidaatsleutel 

meerwaardige afhankelijkheid 


Oefeningen 


ST ON Ge 


normaalvorm 

primaire sleutel 

referentiële integriteitsvoorwaarde 
relatie 

samengestelde determinant 
samengestelde sleutel 
sleutel 

surrogaatsleutel 

tupel 

tweede normaalvorm (2NF) 
verwijderanomalie 

vierde normaalvorm (4NF) 
vijfde normaalvorm (5NF) 
vreemde sleutel 


Noem drie manieren waarop databases kunnen ontstaan. 

Van welke manier gaan we in dit en het volgende hoofdstuk uit? 

Leg uit wat er aan de tabel uit Figuur 3-2 mankeert. 

Definieer elk van de in Figuur 3-3 genoemde termen. 

Beschrijf de kenmerken van een tabel die deze tot een relatie maken. 
Geef een voorbeeld van een tabel die geen relatie is. 


Stel dat twee kolommen in twee verschillende tabellen dezelfde kolomnaam 


hebben. Welke conventie wordt er gebruikt om elk daarvan een unieke naam te 


geven? 


Moeten alle waarden in dezelfde kolom van een relatie dezelfde lengte hebben? 


g. Noem de drie verschillende reeksen termen die worden gebruikt voor het be- 
schrijven van tabellen, kolommen en rijen. 


IO, 


Leg uit wat het verschil is tussen functionele afhankelijkheden die optreden 


door een formule en die om andere redenen optreden. 
rr. Wat betekent de functionele afhankelijkheid Onderdeelnummer > Onderdeel- 


Gewicht intuïtief gezien? 
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Leg uit wat de volgende verklaring betekent: ‘Het opslaan van instanties van 
functionele afhankelijkheden is de enige reden voor het hebben van relaties.” 
Wat betekent de expressie (Voornaam, Achternaam) > Telefoon? 

Wat is een samengestelde determinant? 

Als (A, B) > C, kunnen we dan ook zeggen dat A > C? 


. Als A > (B, C), kunnen we dan ook zeggen dat A > Bì 


Leg uit waarom Inkoper Afdeling bepaalt, maar Afdeling Inkoper niet bepaalt 
voor de tabel ARTIKEL uit Figuur 3-1. 

Leg uit waarom Artikelomschrijving > (Artikelnummer, Afdeling, Inkoper) voor 
de tabel ARTIKEL uit Figuur 3-1. 

Stel dat Onderdeelnummer > OnderdeelGewicht. Betekent dit dat Onderdeel- 
nummer uniek zal zijn in een relatie? 


„ Onder welke omstandigheden zal een determinant uniek zijn in een relatie? 


Wat is een sleutel? 


. Wat is een samengestelde sleutel? 


Wat is een kandidaatsleutel? 


. Wat is een primaire sleutel? 


Leg uit wat het verschil is tussen een kandidaatsleutel en een primaire sleutel. 


„ Wat is een surrogaatsleutel? 


Waar komt de waarde van een surrogaatsleutel vandaan? 


. Wanneer zou je een surrogaatsleutel gebruiken? 
. Wat is een externe sleutel? 


De term thuissleutel wordt niet gebruikt. Maar wat zou deze term volgens jou 
betekenen, als deze wel werd gebruikt? 

Wat is een normaalvorm? 

Demonstreer aan de hand van een voorbeeld de verwijder-, wijziging- en invoe- 
ganomalieën voor de relatie STUDENTENACTIVITEIT uit Figuur 3-20. 

Leg uit waarom dubbele gegevens tot problemen leiden met de integriteit van de 
gegevens. 

Welke relaties zijn in INF? 

Welke normaalvormen houden zich bezig met functionele afhankelijkheden? 


. Onder welke voorwaarden is een relatie in a2NF? 


Onder welke voorwaarden is een relatie in 3NF? 
Onder welke voorwaarden is een relatie in BCNF? 


. Als een relatie in BCNF is, wat kun je dan zeggen over 2NF en 3NE? 
. Welke normaalvorm houdt zich bezig met meerwaardige afhankelijkheden? 


Waar gaat Fagins werk over DK/NF van uit? 


. Vat de drie categorieën van de normalisatietheorie samen. 


Leg in het algemeen uit hoe je een relatie die niet in BCNF is, kunt omzetten in 
relaties die in BCNF zijn. 


„ Wat is een referentiële integriteitsvoorwaarde? 


Leg uit welke rol referentiële integriteitsvoorwaarden spelen bij het normaliseren. 


. Waarom lijkt een niet-genormaliseerde relatie op een alinea met meer 


onderwerpen? 
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ERIS 47. Waarom is de relatie TOTAALPRIJS onnodig in voorbeeld 3, paragraaf 3.4.7? 
48. Onder welke omstandigheden is (SID, Club) + Kosten beter dan Club > Kosten 
in voorbeeld 4, paragraaf 3.4.8? 
49. Is het goed genoeg voor BCNF als een determinant deel uitmaakt van een 
kandidaatsleutel? 


5o. Waarom zijn de volgende twee tabellen onjuist in voorbeeld 5, paragraaf 3.4.9? 


AFDELING (Afdeling, Afdelingsbudgetcode, Inkoper) 
ARTIKEL4 (Artikelnummer, Artikelomschrijving, Afdeling) 


51. Waarin verschilt een meerwaardige afhankelijkheid van een functionele 
afhankelijkheid? 


52. Denk eens na over de relatie: 
PERSOON (Naam, Familieleden, Schoenmaat) 


Neem aan dat Naam > > Familieleden en Naam > Schoenmaat. 
Beschrijf de verwijder-, wijziging- en invoeganomalieën voor deze relatie. 
53. Breng de relatie PERSOON uit de vorige vraag in 4NF. Licht je aanpak toe. 
54. Denk eens na over de relatie: 
PERSOON.2 (Naam, Familieleden, Schoenmaat, Hobby) 
Neem aan dat Naam > — Familieleden, Naam > Schoenmaat en Naam > — Hob- 


by. Beschrijf de verwijder-, wijziging- en invoeganomalieën voor deze relatie. 
55. Breng de relatie PERSOON _2 in 4NF. Licht je aanpak toe. 
56. Wat is een andere term voor 5NF? 


57. In hoeverre komen de voorwaarden voor DK/NF overeen met die voor BCNF? 


Projectvragen 


58. Denk na over de tabel: 
STAF VERGADERING (Werknemernaam, Projectnaam, Datum) 


De rijen van deze tabel registreren het feit dat een werknemer die aan een be- 
paald project werkt op een gegeven datum deelnam aan een vergadering. Neem 
aan dat projectdeelnemers hooguit eenmaal per dag vergaderen. Neem verder 
aan dat een gegeven project door een enkele werknemer wordt gerepresenteerd, 


maar dat werknemers aan meer projecten tegelijk kunnen werken. 
a. Noem de functionele afhankelijkheden. 


b. Zet deze tabel om in een of meer tabellen die in BCNF zijn. Noem de 
primaire sleutels, kandidaatsleutels, externe sleutels en referentiële 
integriteitsvoorwaarden. 

C. 


Is je ontwerp uit vraag b beter dan de originele tabel? Welke voor- en nade- 
Jen heeft je ontwerp? 
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59. Denk na over de tabel: 


STUDENT (Nummer, Naam, Studentenflat, SoortFlat, Flatkosten, 
Club, Clubkosten, Familieleden, Bijnaam) 


Neem aan dat studenten verschillende kosten betalen voor studentenflats, af- 

hankelijk van het soort flat dat ze hebben, maar dat alle leden van een club de- 

zelfde kosten betalen. Neem aan dat een student meer bijnamen kan hebben. 

a. Noem alle eventuele meerwaardige afhankelijkheden. 

b. Noem de functionele afhankelijkheden. 

c. Zet deze tabel om in twee of meer tabellen, zodat elke tabel in BCNF en in 
ANF is. Noem de primaire sleutels, kandidaatsleutels, externe sleutels en 
referentiële integriteitsvoorwaarden. 


Marcia’s Chemische Reiniging 


À. 


Neem aan dat Marcia een tabel bijhoudt over haar klanten. Kijk alleen naar het 
volgende deel van deze tabel: 


CUSTOMER (Phone, FirstName, LastName) 


Leg uit onder welke omstandigheden elk van de volgende uitdrukkingen waar 
is: 

Phone > (FirstName, LastName) 

(Phone, FirstName) > LastName 

(Phone, LastName) > FirstName 

(LastName, FirstName) > Phone 

Phone > > LastName 

Phone > > FirstName 

Phone > > (FirstName, LastName) 


SIOD IN 


Is voorwaarde 7 hetzelfde als voorwaarde 5 en 6? Waarom (niet)? 
Noem een geschikte referentiële integriteitsvoorwaarde voor de volgende 
tabellen. 


CUSTOMER (Phone, FirstName, LastName) 
ORDER (OrderNumber, Dateln, Date0Out, Phone) 


Bekijk de volgende tabellen: 


CUSTOMER (Phone, FirstName, LastName) 
ORDER (OrderNumber, DateIn, Date0Out, FirstName, LastName) 


Wat betekent de volgende referentiële integriteitsvoorwaarde? 


5 


1m 


DEEL2,| DATABASES ONTWERPEN 


ORDER. (FirstName, LastName) moet bestaan in 7 
CUSTOMER. (FirstName, LastName) î 


Is deze voorwaarde hetzelfde als die hieronder? 


ORDER.FirstName moet bestaan in CUSTOMER.FirstName 
ORDER. LastName moet bestaan in CUSTOMER.LastName 


Leg uit waarom, of waarom niet. 


Geef je de voorkeur aan het ontwerp uit C of het ontwerp uit D? Leg je redene- 
ring uit. 

Zet de volgende tabel om in twee of meer tabellen in BCNF en 4NF. Noem de 
primaire sleutels, kandidaatsleutels, externe sleutels en referentiële integriteits- 
voorwaarden. Maak waar nodig aannames en noem deze. 


ORDER (CustomerNumber, FirstName, LastName, Phone, 


Bestellingnummer, Dateln, DateOut, ItemType, Aantal, 
ItemPrice, Totaalprijs, SpecialInstructions) 


Leg uit hoe je antwoord op vraag F verandert, afhankelijk van of je aanneemt dat 


CustomerNumber > (FirstName, LastName), of dat CustomerName > — (First- 
Name, LastName). 


Importbedrijf Morgan 


A. Morgan houdt een tabel bij met gegevens over de winkels waar hij dingen koopt. 
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De winkels bevinden zich in verschillende landen en zijn in verschillende arti- 
kelen gespecialiseerd. Kijk eens naar de volgende relatie: 


STORE (Name, City, Country, Owner, Specialty) 


Leg uit onder welke omstandigheden de volgende verklaringen waar zijn: 
Name > City 


City > Name 

City + Country 

(Name, Country) > (City, Owner) 
(City, Specialty) > Name 

Owner > > Name 

Name > > Specialty 
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B. Wat betreft de relatie in vraag A: 


1. Geef op welke afhankelijkheden in vraag A het meest toepasselijk lijken 
voor een klein import-/exportbedrijf. 

2. Zet, uitgaande van je aannames uit Br, de tabel STORE om in een verzame- 
ling tabellen die zowel in BCNF als in 4NF zijn. Noem de primaire sleutels, 
kandidaatsleutels, externe sleutels en referentiële integriteitsvoorwaarden. 


C. Kijk eens naar de relatie: 


SHIPMENT (ShipmentNumber, VendorName, VendorContact, 
VendorfFax, DepartureDate, ArrivalDate, 
CountryOfOrigin, Destination, ShipmentCost, 
InsuranceValue, Insurer) 


t. Schrijf een functionele afhankelijkheid die aangeeft dat de kosten van het 
verschepen van een lading tussen twee steden altijd hetzelfde zijn. 

2. Schrijf een functionele afhankelijkheid die aangeeft dat de verzekerde waar- 
de altijd hetzelfde is voor een gegeven verkoper. 

3. Schrijf een functionele afhankelijkheid die aangeeft dat de verzekerde waar- 
de altijd hetzelfde is voor een gegeven verkoper en land van oorsprong. 
Beschrijf twee mogelijke meerwaardige afhankelijkheden in SHIPMENT. 

5. Noem functionele afhankelijkheden die volgens jou redelijk zijn voor de re- 
latie SHIPMENT voor een klein import-/exportbedrijf. 

6. Noem meerwaardige afhankelijkheden die volgens jou redelijk zijn voor de 
relatie SHIPMENT. 

7. Zet SHIPMENT, uitgaande van je aannames uit vraag 5 en 6, om in een ver- 
zameling tabellen die in BCNF en in 4NF zijn. Noem de primaire sleutels, 
kandidaatsleutels, externe sleutels en referentiële integriteitsvoorwaarden. 
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Hoofdstuk 4 
Databases ontwerpen met 
behulp van normalisatie 


We hebben in hoofdstuk 3 het relationele model gedefinieerd, wijziginganomalieën 
beschreven en normalisatie met behulp van BCNF en 4NF besproken. We passen deze 
ideeën in dit hoofdstuk toe op het ontwerpen van databases op basis van bestaande 
gegevens. 

In dit hoofdstuk gaan we ervan uit dat je een of meer tabellen met gegevens uit 
een bepaalde bron hebt gekregen, die in de vorm van een nieuwe database moeten 
worden opgeslagen. De vraag is: moeten deze gegevens in hun huidige vorm worden 
opgeslagen of moeten ze worden omgezet voordat ze worden opgeslagen? Zoals je zult 
zien, speelt de normalisatie hierbij een belangrijke rol. 
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41 De tabelstructuur analyseren 


Als iemand je een stel tabellen geeft en vraagt daarmee een database te maken, zou 
de eerste stap die je doet het analyseren van de structuur en de inhoud van deze ta- 


bellen moeten zijn. Figuur 4-1 geeft algemene richtlijnen voor het beoordelen van de 
structuur van een tabel. 


Tel rijen en onderzoek kolommen. 

Onderzoek gegevenswaarden en overleg met gebruikers voor het bepalen van: _ | 
- Meerwaardige afhankelijkheden S _ 

- Functionele afhankelijkheden 7 atd 
- Kandidaat-sleutels : : | 
= Primaire sleutels Be p 
- Externe sleutels PK | 
Beoordeel de geldigheid van veronderstelde referentiële integriteitsvoorwaarden. 


Figuur 4-1 Richtlijnen voor het beoordelen van de structuur van een tabel 


Tel om te beginnen het aantal rijen in elke tabel met de SQL-functie COUNT (*). 
Gebruik daarna SELECT * om te bepalen hoeveel kolommen de tabel heeft en 
van welk type deze kolommen zijn. Een volledige query kan behoorlijk wat tijd in be- 
slag nemen als de tabel duizenden of miljoenen rijen heeft. je kunt het resultaat van 
deze query beperken door het sleutelwoord TOP te gebruiken. Je zou bijvoorbeeld 


het volgende SQL-statement schrijven om alle kolommen op te halen van de eerste 
tien rijen van de tabel ARTIKEL: 


SELECT TOP 10 * 
FROM ARTIKEL; 


Deze query toont je alle kolommen en gegevens voor tien rijen. Wil je de eerste vijf. 
tig rijen zien, dan gebruik je gewoon TOP so, in plaats van TOP ro, enzovoort. 

Zoals je in Figuur 4-1 ziet, moet je de gegevens onderzoeken en de functionele 
afhankelijkheden, de meerwaardige afhankelijkheden, de kandidaat-sleutels en de 
primaire sleutel van elke tabel bepalen. Zoek ook naar mogelijke externe sleutels. 
Nogmaals: je kunt je conclusies baseren op voorbeeldgegevens, maar die zullen mis- 
schien niet representatief genoeg zijn. Je moet je aannames en conclusies daarom 
controleren door met de gebruikers te spreken. 

Wat betreft externe sleutels: het is gevaarlijk aan te nemen dat er al referentiële 
integriteitsvoorwaarden zijn toegepast op de gegevens. Je moet dat in plaats daarvan 


zelf controleren. Neem bijvoorbeeld aan dat je gegevens hebt gekregen voor de vol- 
gende twee tabellen: 


ARTIKEL (Artikelnummer, Artikelomschrijving, Afdeling, Inkoper) 
en 
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INKOPER (Inkoper, Afdeling) 


Je kwam tijdens het onderzoek te weten dat Artikelnummer de primaire sleutel is 
van ARTIKEL en dat Inkoper de primaire sleutel is van INKOPER. Je denkt ver- 
der dat het waarschijnlijk is dat ARTIKEL. Inkoper een externe sleutel is voor IN- 
KOPER.Inkoper. De vraag is of de volgende referentiële integriteitsvoorwaarde is 
aangehouden: 


ARTIKEL. Inkoper moet bestaan in INKOPER. Inkoper 


Je kunt SQL gebruiken om te bepalen of dat het geval is. De volgende query zal alle 
waarden van de externe sleutel leveren die niet aan deze voorwaarde voldoen: 


SELECT Inkoper 
FROM ARTIKEL 
WHERE Inkoper NOT IN 


(SELECT Inkoper 
FROM ARTIKEL, INKOPER 
WHERE ARTIKEL. Inkoper = INKOPER. Inkoper); 


De subquery vindt alle waarden van Inkoper waarvoor ARTIKEL.Inkoper en IN- 
KOPER.Inkoper overeenkomen. Mochten er waarden van Inkoper bestaan die 
niet in het resultaat van deze subquery voorkomen, dat worden deze door de bo- 
venste query weergegeven. Dergelijke waarden schenden allemaal de referentiële 
integriteitsvoorwaarde. 

Heb je de invoertabellen eenmaal geanalyseerd, dan zullen je volgende stappen 
afhankelijk zijn van of je een updatable database wilt maken of een read-only-data- 
base. We zullen de updatable databases het eerst behandelen. 


4.2 Updatable databases ontwerpen 


Als je een updatable database wilt maken — een database waarin je wijzigingen in de 
gegevens kunt aanbrengen — moet je rekening houden met wijziginganomalieën en 
tegenstrijdige gegevens. Dat betekent dat je de principes van het normaliseren pre- 
cies moet aanhouden. Laten we, voordat we beginnen, eerst de voor- en nadelen van 
het normaliseren doornemen. 


4.2.1 De voor- en nadelen van normalisatie 

In Figuur 4-2 zie je de voor- en nadelen van het normaliseren. De positieve kant is 
dat normalisatie wijziginganomalieën verwijdert en het dupliceren van gegevens be- 
perkt. Het verminderen van het dupliceren van gegevens voorkomt integriteitspro- 
blemen als gevolg van inconsistente gegevens. En het spaart opslagruimte uit. 
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Voordelen en np | 
verwijdert wijziginganomalieën. 7 ] 
Vermindert dubbele gegevens. E 
Voorkomt integriteitsproblemen. 
Spaart opslagruimte uit. | 
Nadelen À 
ingewikkelder SQL om gegevens uit verschillende tabellen te krijgen. 
Extra werk voor het DBMS, kan de snelheid van de applicatie verminderen. 


Figuur 4-2 Voor- en nadelen van normalisatie 


De negatieve kant is dat applicatieprogrammeurs ingewikkelder SQL moeten schrij- 
ven. Om de oorspronkelijke gegevens terug te krijgen, moeten ze subquery’s en 
joins schrijven die werken op diverse tabellen. Bovendien moet het DBMS met ge- 


normaliseerde gegevens uit twee of meer tabellen lezen, wat tot langzamere verwer- 
king kan leiden. 


4.2.2 Functionele afhankelijkheden 


Je zag in hoofdstuk 3 dat we door functionele afhankelijkheden veroorzaakte ano- 
malieën kunnen verwijderen door alle tabellen in BCNF te brengen. Wijziginga- 
nomalieën veroorzaken in de meeste gevallen dermate grote problemen dat je de 


tabellen in BCNF moet brengen. Er zijn echter uitzonderingen, zoals je zult zien in 
paragraaf 4.2.4. 


4.2.3 Normaliseren met SQL 


Zoals we in hoofdstuk 3 bespraken, is een tabel in BCNF als alle determinanten kan- 
didaat-sleutels zijn. Is er een determinant die geen kandidaat-sleutel is, dan moeten 


we de tabel in twee of meer tabellen onderverdelen. Stel dat je de tabel REPARATIE 
uit Figuur 4-3 krijgt (dezelfde tabel als in Figuur 3-12). 


REPARATIE 


| Itemnummer [_ Type __ | Aanschafprijs | Reparatienummer 


|__100___|Kolomboor |___C 3.500,00 2000 
€4.750,00 2100 


2200 
zoo [was | 273000 | 


Figuur 4-3 De tabel REPARATIE 


Reparatiedatum | Reparatiekosten | 
2-9-2010 € 375,00 
18-9-2010 € 255,00 
30-9-2010 € 178,00 

2-9-2010 €1.875,00 _ | 
24-9-2010 € 0,00 
29-9-2010 € 275,00 


We zagen in hoofdstuk 3 dat Itemnummer een determinant is maar geen kandi- 
daat-sleutel. We hebben daarom de tabellen ITEM en REPARATIE2 gemaakt. Item- 
nummer is in deze tabellen een determinant en een kandidaat-sleutel voor ITEM. 


Reparatienummer is een determinant en de primaire sleutel van REPARATIE2. Dat 
betekent dat beide tabellen in BCNF zijn. 
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ITEM | 
itemnummer Type__| Aanschaf 
100 Kolomboor __|__€ 3.500,00 
| 200 Draaibank - € 4.750,00 
[ 300 |wals € 27.300,00 
( REPARATIE2 
hepsotienammer | Itemnummer Reparatiedatum Reparatiekosten | 
2000 100 2-9-2010 € 375,00 
L 2200 100 30-9-2010 €178,00 | 
2400 | 100 24-9-2010 €0,00 
2500 | 100 29-9-2010 | € 275,00 
2100 200 18-9-2010 € 255,00 
2300 300 | 2-9-2010 |__ €1.875,00 


Figuur 4-4 Voorbeeldgegevens voor de relaties ITEM en REPARATIE2 


De vraag is: hoe zet je in de praktijk de gegevens met de indeling van Figuur 4-3 om 
in die van Figuur 4-4? Het antwoord is het SQL-sleutelwoord INSERT. Je zult meer 
over deze opdracht te weten komen in hoofdstuk 7. We lopen daar nu echter op voor- 
uit en gebruiken een versie van deze opdracht om toe te lichten hoe het normalise- 
ren in de praktijk verloopt. 

Als je deze oefening wilt uitvoeren, download dan de Microsoft Access-database 
Reparatie.accdb van de website bij dit boek (www.pearsoneducation.nl/kroenke). 
Deze database bevat de tabel REPARATIE, met de voorbeeldgegevens. Maak de nieu- 
we tabellen (zie bijlage A) ITEM en REPARATIE2 en voer voor het normaliseren de 
volgende INSERT-statements uit. 

Eerst de opdracht voor het invullen van de tabel ITEM: 


INSERT INTO ITEM 
SELECT DISTINCT Itemnummer, Type, Aanschafprijs 
FROM REPARATIE; 


Je moet het sleutelwoord DISTINCT gebruiken omdat de combinatie (ltemnummer, 
Type, Aanschafprijs) niet uniek is in de tabel REPARATIE. Vervolgens vul je de rijen 
van REPARATIE2 in met de volgende INSERT-opdracht: 


INSERT INTO REPARATIE2 


SELECT Itemnummer, Reparatienummer, Reparatiedatum, 
Reparatiekosten 
FROM REPARATIE; 


Zoals je ziet zijn de SQL-statements voor het normaliseren van tabellen relatief een- 
voudig. Het is waarschijnlijk het beste om de tabel REPARATIE te verwijderen, als je 
klaar bent met het omzetten daarvan, en de naam van REPARATIE2 te veranderen 
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in REPARATIE. Je kunt dit doen met behulp van de grafische interface in Access: 
klik met de rechter muisknop op de naam van de tabel. In hoofdstuk 7 leer je hoe je 
een tabel verwijdert met behulp van het SQL DROP-statement. 


vepn aman, 


4.2.4 Wanneer gebruik je geen BCNF? 

Hoewel in de meeste gevallen de tabellen van een updatable database in BCNF moe- 
ten zijn, is dat in sommige situaties te veel van het goede. Het klassieke voorbeeld 
van onnodige normalisatie is de in de USA gebruikte postcode (zipcode). Bekijk de 
volgende tabel voor klanten in de Verenigde Staten: 


CUSTOMER (CustomerID, LastName, FirstName, Street, City, State, 
Zip) 


De functionele afhankelijkheden in deze tabel zijn: 


CustomerID — (LastName, FirstName, Street, City, State, Zip) 
Zip — (City, State) 


Deze tabel is niet in BCNF omdat Zip een determinant is, maar geen kandidaat- 
sleutel. We kunnen de tabel als volgt normaliseren: 


CUSTOMER 2 (CustomerID, LastName, FirstName, Street, Zip) 
ZIP CODE (Zip, City, State) 


Met de referentiële integriteitsvoorwaarde: 
CUSTOMER 2.Zip moet bestaan in ZIP _CODE.Zip 


De tabellen CUSTOMER 2 and ZIP_CODE zijn in BCNF, maar bekijk deze tabel- 
len in het licht van de voor- en nadelen die genoemd staan in Figuur 4-2. Norma- 
lisatie verwijdert wijziginganomalieën, maar hoe vaak veranderen de gegevens die 
betrekking hebben op de postcode? Hoe vaak wijzigen de stad en de staat die aan een 
bepaalde postcode zijn gekoppeld? Vrijwel nooit. In de praktijk zullen de wijziging- 
anomalieën zich niet voordoen. 

Bekijk het tweede voordeel: normalisatie reduceert gegevensduplicatie en verbe- 
tert daardoor de integriteit van de gegevens. Een integriteitsprobleem doet zich in 
de enkelvoudige tabel voor als iemand een verkeerde waarde voor City. State of Zip 
invoert. In dat geval heeft de database inconsistente Zip-gegevens. Maar normaal ge- 
sproken zullen zulke fouten wel opvallen en gecorrigeerd worden. 

Kijk nu eens naar de nadelen van normalisatie. De twee tabellen vragen ingewik- 
kelder SQL Bovendien moet het DBMS twee tabellen verwerken, wat de applicatie 
langzamer ken maken. Als je de voor- en nadelen tegen elkaar afweegt, zuilen de 
meeste ervaringsdeskundigen zeggen dat normalisatie in dit geval iets te veel van 


het goede iS. 
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Samengevat: Als je een updatable database ontwerpt op grond van bestaande gege- 
vens, onderzoek dan elke tabel om te zien of hij in BCNF is. Als dat niet het geval is, 
is de tabel gevoelig voor wijziginganomalieën en inconsistente gegevens. In vrijwel 
alle gevallen transformeer je de tabel in tabellen die in BCNF zijn. Maar als de gege- 
vens nooit wijzigen en als inconsistente gegevens makkelijk te corrigeren zijn, kun 
je ertoe besluiten de tabel niet in BCNF te brengen. 


4.2.5 Meerwaardige afhankelijkheden 

De door meerwaardige afhankelijkheden veroorzaakte anomalieën zijn, in tegenstel- 
ling tot de door functionele afhankelijkheden veroorzaakte anomalieën, zo zwaar- 
wegend dat meerwaardige afhankelijkheden altijd moeten worden verwijderd. Er is, 
anders dan bij BCNF, geen grijs gebied. Je moet de kolommen van een meerwaar- 
dige afhankelijkheid altijd in eigen tabellen onderbrengen. 

Zoals je in de vorige paragraaf zag, is het normaliseren niet moeilijk. Het norma- 
liseren houdt echter wel in dat applicatieprogrammeurs subquery’s en joins moeten 
schrijven om de originele gegevens te achterhalen. Het schrijven van subquery’s en 
joins is echter vrij simpel in vergelijking met de ingewikkelde code die moet worden 
geschreven voor het omgaan met anomalieën die optreden vanwege meerwaardige 
afhankelijkheden. 


4.3 Read-only-databases ontwerpen 


Zoals je in hoofdstuk 13 zult zien, worden read-only-databases gebruikt voor rap- 
portage- en dataminingapplicaties. De richtlijnen en prioriteiten voor het ontwer- 
pen van dergelijke databases verschillen van die voor updatable databases, omdat ze 
nooit worden bijgewerkt. 

Het normaliseren van een read-only-database levert maar zelden een voordeel op. 
Daar zijn diverse redenen voor. In de eerste plaats kunnen er geen problemen op- 
treden met de integriteit van de gegevens en er kunnen geen wijziginganomalieën 
optreden omdat de database nooit wordt bijgewerkt. Dat betekent, als we Figuur 4-2 
bekijken, dat het verminderen van het aantal dubbele gegevens de enige reden is 
voor het normaliseren van een read-only-database. 

De opslagkosten voor databasebestanden zijn tegenwoordig minimaal, tenzij de 
database werkelijk gigantisch groot is. Het is wel waar dat grote tabellen betekenen 
dat het DBMS er langer over zal doen gegevens te vinden en te verwerken. De gege- 
vens kunnen dus genormaliseerd worden om de verwerking sneller te maken. Maar 
zelfs dat voordeel is niet altijd van toepassing. Er zullen misschien gegevens uit twee 
of meer tabellen moeten worden gelezen als de gegevens zijn genormaliseerd en de 
join kan meer tijd in beslag nemen dan er wordt gewonnen doordat er met kleinere 
tabellen wordt gewerkt. Het is vrijwel nooit een goed idee de tabellen van een read- 
only-database te normaliseren. 
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43.1 Denormaliseren 
De gegevens voor read-only-databases worden vaak uit operationele databases ge- 
extraheerd. Dergelijke databases zijn updatable en zijn daarom waarschijnlijk al 
genormaliseerd. Dat betekent dat je de geëxtraheerde gegevens waarschijnlijk in ge- 
normaliseerde vorm krijgt. 

Zoals de vorige paragraaf aangeeft, wil je de gegevens waarschijnlijk niet in de 
genormaliseerde vorm laten staan voor een read-only-database. Je moet de gegevens 
in dat geval denormaliseren, of combineren. 

Neem het voorbeeld uit Figuur 4-5. Dit is een kopie van de genormaliseerde ge- 

gevens voor studenten/clubs/betalingen uit Figuur 3-21. Stel dat je een read-only- 
database aan het maken bent, die zal worden gebruikt voor het rapporteren van 
achterstallige betalingen voor studentenclubs. Zou je de gegevens in deze vorm met 
drie tabellen opslaan, dan zouden de drie tabellen telkens moeten worden samenge- 
voegd als iemand Betaald met Kosten wil vergelijken. Dat betekent dat deze persoon 
moet weten hoe hij of zij een join voor drie tabellen schrijft en dat het DBMS deze 
join telkens moet uitvoeren als het rapport wordt voorbereid. 


Duiken 


|_____BHAUNG | 
[so] cb | getaald | 
100 | Duiken € 0,00 

200 | Duiken 
200 |sken _ | €ssooo | 


Figuur 4-5 Kopie van de genormaliseerde gegevens voor studenten /clubs/betalingen uit Figuur 3-21 


Je kunt de ingewikkeldheid van de SQL die nodig is voor het lezen van deze gegevens 
en de verwerking door het DBMS, verminderen door de tabellen maar eenmaal sa- 
men te voegen en het samengevoegde resultaat op te slaan als een enkele tabel. Het 
volgende SQL-statement voegt de drie tabellen samen en slaat ze op in een nieuwe 
tabel met de naam BETALINGSGEGEVENS: 
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INSERT INTO BETALINGSGEGEVENS 
SELECT STUDENT.SID, Naam, CLUB.Club, Kosten, Betaald 
FROM STUDENT, BETALING, CLUB 
WHERE STUDENT.SID = BETALING.SID 
AND BETALING.Club = CLUB.Club:; 
BETALINGSGEGEVENS 

[sio | Naam | club ] Kosten | Betaald 

| 100 |jong | Duiken |_ €400,00 | _ €0,00 

| 200 | oud | Duiken |_c40o,00 | €400,00 

| 200 [oud | skien | €550,00 | €550,00 

[300 [Gerits |Klimmen | €150,00 | €150,00 

| 400 [jong | skiën |_€550,00 | €550,00 


Figuur 4-6 De gedenormaliseerde relatie BETALINGSGEGEVENS 


Zoals je ziet, is het resultaat van deze samenvoeging gelijk aan de originele tabel in 
Figuur 3-20. 

Je ziet dat het denormaliseren eenvoudig is. Je voegt de gegevens gewoon samen 
en slaat het samengevoegde resultaat op als een tabel. Hierdoor zorg je ervoor dat 
de applicatieprogrammeurs geen joins hoeven te schrijven voor elke applicatie en 
dat het DBMS niet telkens joins en subquery's moet uitvoeren als de gebruikers een 
query uitvoeren of een rapport maken. 


4.4 Veelvoorkomende ontwerpproblemen 


Het normaliseren en het denormaliseren vormen de belangrijkste aandachtspunten 
bij het ontwerpen van databases op basis van bestaande gegevens. Er zijn daarnaast 
echter nog vier andere problemen waarmee je rekening moet houden. Zie Figuur 


47. 


«Probleem met meer kolommen voor meer waarden 
*_Inconsequente gegevens 
*_ Ontbrekende waarden 

*_ Kolommen met algemene opmerkingen 


Figuur 4-7 Problemen die in de praktijk optreden bij het ontwerpen van databases op basis van bestaande 
gegevens 


4.4.1 Het probleem met meer kolommen voor meer waarden 

Stel dat een bedrijf een tabel PRODUCT heeft met kolommen zoals die genoemd 
staan in Figuur 4-8. Hierin zie je onder andere kolommen voor Leveranciercontactr 
en Leveranciercontact2. Deze kolommen worden gebruikt om de namen van twee 
contactpersonen bij leveranciers van producten op te slaan. 


127 


vas 


5 


DEEL? | DATABASES ONTWERPEN 


Figuur 4-8 Tabel PRODUCT 


Wil het bedrijf de namen van drie of vier contactpersonen opslaan met deze strate- 
gie, dan voegt het de kolommen Leveranciercontact3, Leveranciercontact4 toe, enzo- 


voort. Een tweede voorbeeld is een applicatie voor parkeerplaatsen voor werknemers. 
Stel dat de tabel WERKNEMER basisgegevens over de werknemers bevat, plus ko- 


lommen voor de namen van maximaal drie eventuele kinderen. Een dergelijke tabel 
zal er gewoonlijk ongeveer zo uitzien: 


WERKNEMER _AUTO (WnNummer, Naam, E-mail, Kindl, Kind2, Kind3) 
Een ander voorbeeld van deze strategie is kolommen met namen zoals Fotor, Fotoa, 
Foto3, enzovoort, voor het opslaan van foto’s van een huis voor een makelaarsapplicatie. 

Het is handig meer waarden op deze manier op te slaan, maar er zijn twee zwaar- 
wegende nadelen. Het meest voor de hand liggende nadeel is dat het aantal moge- 
lijke items onveranderlijk is. Wat gebeurt er als er drie contactpersonen zijn bij een 
bepaalde leverancier? Waar moet je de derde naam laten als alleen de kolommen 
Leveranciercontactr en Leveranciercontacta beschikbaar zijn? Of waar moet je de 
naam van het vierde kind laten als er maar drie kolommen zijn voor namen van kin- 
deren? Enzovoort. 

Het tweede nadeel treedt op bij het zoeken in de gegevens. Stel dat je de namen 
wilt weten van alle werknemers die een kind hebben met de naam Greta. Zijn er drie 
kolommen met namen van kinderen, dan moet je het volgende schrijven: 


SELECT * 

FROM WERKNEMER 

WHERE Kindl = 'Greta' 
OR Kind2 = 'Greta' 
OR Kind3 = 'Greta'; 


Zijn er echter zeven kolommen met namen van kinderen, dan … nu ja, je begrijpt 
het wel. 


Deze problemen zijn op te lossen door het meerwaardige attribuut in een tweede 
tabel op te slaan. De tabellen zijn voor het geval met werknemer /kind: 


WERKNEMER (WnNummer, WnNaam, E-mail, … overige gegevens) 
KIND (KindNaam, WnNummer, … overige gegevens) 
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Met deze tweede indeling kunnen we per werknemer de gegevens van een onbeperkt 
aantal kinderen opslaan. En we besparen opslagruimte bij werknemers die helemaal 
geen kinderen hebben. We kunnen dan bovendien het volgende schrijven om alle 
werknemers te vinden die een kind met de naam Greta hebben: 


SELEGT * 

FROM WERKNEMER 

WHERE WnNummer IN 
(SELECT WnNummer 
FROM KIND 


WHERE KindNaam = 'Greta'); 


Deze tweede query is makkelijker te schrijven en zal altijd werken, ongeacht het aan- 
tal kinderen van een werknemer. 

Het alternatieve ontwerp vereist wel dat het DBMS twee tabellen verwerkt. We 
kunnen daarom argumenteren dat het originele ontwerp beter is als de tabellen 
groot zijn en de prestaties van belang zijn. In dergelijke gevallen kan het de voor- 
keur hebben meer waarden in meer kolommen op te slaan. Zoals je in hoofdstuk 8 
zult zien, is het herontwerpen van databases lastig, ingewikkeld en duur. Het is beter 
te voorkomen dat het ontwerp van een database moet worden aangepast. 


Opmerking 

Een paar jaar geleden argumenteerden mensen dat er maar drie kolommen voor telefoonnummers nodig 
waren per persoon: Thuis, Kantoor en Fax. Wat later zei men: nu ja, misschien hebben we er vier nodig: 
Thuis, Kantoor, Fax en Mobiel. Wie wil er tegenwoordig nog raden hoeveel telefoonnummers temand 
maximaal kan hebben? In plaats van te raden kun je beter Telefoon opslaan in een afzonderlijke tabel 

— een dergelijk ontwerp staat het iedereen toe van geen tot een onbeperkt aantal telefoonnummers te 
hebben. 


Het is goed mogelijk dat je het probleem met meer kolommen voor meer waarden 
tegenkomt als je databases maakt op basis van gegevens die niet uit databases af- 
komstig zijn. Het probleem komt vooral voor bij spreadsheets en gegevensbestan- 
den in tekstvorm. Het ontwerp met twee tabellen dat de voorkeur heeft, kan gelukkig 
makkelijk worden gemaakt. De SQL voor het verplaatsen van de gegevens naar het 
nieuwe ontwerp, kan makkelijk worden geschreven. 


4.4.2 Inconsequente waarden 

Niet-consequente gegevens vormen een zwaarwegend probleem bij het maken van 
databases op basis van bestaande gegevens. Dat probleem treedt op doordat gebrui- 
kers of gegevensbronnen lichtelijk verschillende vormen kunnen gebruiken van de- 
zelfde gegevenswaarde. Deze kleine verschillen kunnen moeilijk traceerbaar zijn en 
zullen tot inconsequente of foutieve informatie leiden. 
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Een van de moeilijkste problemen treedt op als verschillende gebruikers dezelfde 
items anders hebben geïnterpreteerd. De ene gebruiker kan een Artikelomschrij- 
ving invullen als: T-shirt, medium, geel, en een andere gebruiker als: geel T-shirt, 
medium. 

Er treedt een gerelateerd maar eenvoudiger probleem op als items verkeerd zijn 
gespeld. De ene gebruiker kan Koffie invoeren, de andere Kofie. Deze twee zullen 
dan als verschillende producten worden opgenomen. 

Inconsequente gegevenswaarden zijn vooral problematisch voor kolommen die 
primaire of externe sleutels bevatten. Als externe sleutelgegevens inconsequent zijn 
genoteerd of verkeerd zijn gespeld, zullen er relaties ontbreken en verkeerde relaties 

optreden. 

Er zijn twee technieken voor het vinden van dergelijke problemen. Een techniek 
is hetzelfde als de in paragraaf 4.1 toegepaste controle op referentiële integriteit. 
Deze controle selecteert waarden waar geen overeenkomst voor te vinden is. Ook 
zal deze techniek er spellingsfouten en andere inconsequente gegevens uitfilteren. 

Een andere techniek is het toepassen van GROUP BY op de verdachte kolom. 
We kunnen bijvoorbeeld het volgende schrijven als we denken dat er inconsequente 
waarden voorkomen in Artikelomschrijving van de tabel ARTIKEL: 


SELECT Artikelomschrijving, Count(*) as NameCount 
FROM ARTIKEL 
GROUP BY Artikelomschrijving; 


__Artikelomschrijving ___  NameCount | 
Ouikmasker, medium, helder Pon 
Duikmasker, small, helder 1 
[Grondzeil halvekoepeltent | 1 | 
Karabijnsluiting, ovaal 
Standaard SCUBA, magenta 


Figuur 4-9 Resultaat query met de waarden van ARTIKEL 


Je ziet het resultaat van deze query, met de waarden van ARTIKEL die we tot dus- 
ver gebruikten, in Figuur 4-9. Er zijn in dit geval geen inconsequente waarden. Ze 
zouden echter opvallen als ze er wel zouden zijn. Je kunt groepen met maar een of 
twee elementen selecteren met HAVING, als de met SELECT gemaakte lijst te lang 
is. Geen van deze controles is 100% betrouwbaar. Je zult de gegevens soms gewoon 
moeten lezen. 

Als we met dergelijke gegevens werken, is het belangrijk om een systeem te ont- 
wikkelen voor het rapporteren en bijhouden van fouten. Zo kun je verzekeren dat 
tegenstrijdigheden die gebruikers vinden, worden geregistreerd en verholpen. Ge- 
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bruikers worden al snel zeer ongeduldig als gegevensfouten blijven bestaan nadat ze 
zijn gerapporteerd. 


4.4.3 Ontbrekende waarden 

Ontbrekende waarden vormen een derde probleem dat kan optreden bij het ma- 
ken van databases op basis van bestaande gegevens. Een ontbrekende waarde is een 
waarde die nooit is geleverd. Dit wordt ook wel een nullwaarde (let op: twee ellen) 
genoemd. Dat is niet hetzelfde als een lege waarde, want een lege waarde is een 
waarde waarvan bekend is dat deze leeg is. Van een nullwaarde is niet bekend wat 
de waarde is. 

Het probleem met nullwaarden is dat ze dubbelzinnig zijn. Een nullwaarde kan 
een van drie situaties aangeven: de waarde is niet toepasselijk, de waarde is toepas- 
selijk maar niet bekend of de waarde is toepasselijk en bekend maar niemand heeft 
deze in de database ingevoerd. We zijn niet in staat op basis van een nullwaarde te 
bepalen welke van deze situaties de juiste is. 

Neem bijvoorbeeld een nullwaarde in de kolom DatumMeestRecenteGeboorte in 
een tabel PATIËNT. De nullwaarde treedt op omdat de waarde niet van toepassing 
is als de patiënt een man is — mannen kunnen geen kinderen baren. De waarde kan 
toepasselijk maar onbekend zijn als de patiënt een vrouw is die nooit is gevraagd 
deze informatie te leveren. Tot slot kan de waarde toepasselijk en bekend zijn maar 
heeft niemand de waarde in de database ingevoerd. 

Je kunt de SQL-term IS NULL gebruiken om op nullwaarden te controleren. Je 
schrijft bijvoorbeeld het volgende als je wilt weten hoeveel nullwaarden voorkomen 
in de rij Aantal van de tabel BESTELLING ITEM: 


SELECT COUNT (*) as TelAantalNull 
FROM BESTELLING ITEM 
WHERE Aantal IS NULL; 


Het resultaat van deze query ziet eruit als Figuur 4-10. 


TelAantalNull 


Figuur 4-10 Resultaat IS NULL 


In dit geval zijn er geen nullwaarden. Als dat wel het geval is, kun je een SELECT * 
gebruiken om de gegevens op te halen van elke rij die een nullwaarde bevat. 

Het DBMS geeft een foutmelding als je tijdens het maken van een database op 
basis van bestaande gegevens probeert een kolom die nullwaarden bevat als de pri- 
maire sleutel te definiëren. Je moet de nullwaarden verwijderen voordat je de pri- 
maire sleutel maakt. Je kunt het DBMS ook vertellen dat een gegeven kolom geen 
nullwaarden mag bevatten. Het DBMS zal dan een foutmelding leveren tijdens het 
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importeren van de gegevens als er rijen in die kolom voorkomen die een nullwaarde 
bevatten. 

Je zou er een gewoonte van moeten maken om alle externe sleutels altijd op 
nullwaarden te controleren. Elke rij met een externe sleutel die null is, zal niet aan 
de relatie deelnemen. Dat kan al dan niet toepasselijk zijn — je zult dat aan de ge- 
bruikers moeten vragen. Nullwaarden kunnen bovendien problemen opleveren bij 


het samenvoegen van tabellen. In hoofdstuk 7 zie je hoe je met dat probleem moet 
omgaan. 


4.4.4 De kolom met algemene opmerkingen 

Kolommen met namen zoals Opmerkingen, Commentaar of Notities bevatten vaak 
gegevens die breedsprakig en op een inconsequente manier zijn opgeslagen. Je moet 
altijd oppassen als je kolommen met dergelijke namen tegenkomt. 

Denk om te begrijpen waarom dat zo is, eens na over de klantengegevens van een 
bedrijf dat dure dingen verkoopt, zoals vliegtuigen, raceauto's, boten of schilderijen. 
In de meeste gevallen zal iemand een spreadsheet hebben gebruikt voor het bijhou- 
den van klantengegevens. De betreffende persoon heeft de spreadsheet niet gebruikt 
omdat dit het beste hulpmiddel was voor een dergelijk probleem, maar omdat hij nu 
eenmaal een spreadsheetprogramma had en wist hoe hij daarmee moest omgaan. 

De gebruikelijke spreadsheet heeft kolommen zoals Naam, E-mail, Telefoon, 
Adres, enzovoort. Ook is er vrijwel altijd een kolom met een naam Opmerkingen, 
Commentaar, Notities of iets dergelijks. Het probleem is dat in dergelijke kolom- 
men vaak gegevens zijn begraven die je nodig hebt — en het is vrijwel onmogelijk 
deze gegevens uit te graven. Stel dat je een database wilt maken voor een handelaar 


in vliegtuigen, met een applicatie voor het contact met klanten. Je ontwerp omvat de 
volgende twee tabellen: 


CONTACT (ID, Naam, Adres, overige gegevens 
Vliegtuigmodel) 


en 


VLIEGTUIGMODEL (Model, Type, Beschrijving, overige gegevens 
betreffende het vliegtuig) 


waarbij CONTACT. vVliegtuigmodel een externe sleutel is naar VLIEGTUIGMODEL. 
Model. Je wilt deze relatie gebruiken om te bepalen of iemand de eigenaar is van, de 
eigenaar was van, of geïnteresseerd is in het kopen van een bepaald model vliegtuig. 
De gegevens voor de externe sleutel zullen in het gebruikelijke geval zijn gere- 
gistreerd in de kolom Opmerkingen. Als je de gegevens onder Opmerkingen leest, 
zul je dingen vinden als: ‘Wil een Piper Seneca II kopen’, ‘Eigenaar van een Piper 
Seneca II’ en ‘Wil misschien een Turbo Seneca kopen’. VliegtuigModel zou voor 
deze drie rijen de waarde ‘Piper Seneca II’ moeten hebben, maar je zult je de haren 
uit het hoofd trekken voordat je de juiste waarde hebt bepaald voor elke rij. 
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Een ander probleem met kolommen met algemene opmerkingen is dat ze niet op 
een consequente manier worden gebruikt en vaak meer gegevens bevatten. De ene 
gebruiker kan er de levenspartner van de contactpersoon in hebben opgeslagen, ter- 
wijl iemand anders deze op de zojuist beschreven manier heeft gebruikt voor het 
opslaan van vliegtuigmodellen en nog weer iemand anders voor het opslaan van de 
datum waarop er voor het laatst contact was met deze klant. Dezelfde gebruiker zal 
deze kolom misschien zelfs voor alle drie de doeleinden hebben gebruikt. 

Het is in dat geval het beste om alle verschillende doeleinden van de opmerkin- 
genkolom te bepalen, nieuwe kolommen voor elk van die doeleinden te maken, de 
gegevens vervolgens te extraheren en ze steeds in de juiste kolom op te slaan. Deze 
oplossing is echter vrijwel nooit te automatiseren. 

Alle oplossingen vereisen in de praktijk veel geduld en veel werk. Leer op je hoede 
te zijn voor dergelijke kolommen — en neem dergelijke klussen nooit aan voor een 
vooraf vastgestelde prijs. 


Samenvatting 


De eerste stap voor het maken van een database op basis van bestaande gegevens is 
het analyseren van de structuur en de inhoud van de invoertabellen. Tel het aantal 
rijen en gebruik SELECT TOP ro * om te zien in welke kolommen de gegevens zijn 
verdeeld. Bekijk daarna de gegevens en bepaal de functionele afhankelijkheden, de 
meerwaardige afhankelijkheden, de primaire sleutel van elke tabel en de externe sleu- 
tels. Controleer de geldigheid van mogelijke referentiële integriteitsvoorwaarden. 

De ontwerpprincipes verschillen afhankelijk van of er een updatable of een read- 
only-database wordt gemaakt. In het eerste geval moet je rekening houden met wij- 
ziginganomalieën en inconsequente gegevens. De voordelen van normaliseren zijn 
dat wijziginganomalieën worden verwijderd, dat het aantal dubbele gegevens ver- 
mindert en dat inconsequente gegevens worden geëlimineerd. 

De meeste door wijziginganomalieën veroorzaakte problemen zijn zo zwaarwe- 
gend bij updatable databases dat alle tabellen in BCNF moeten worden gebracht. De 
SQL voor het normaliseren kan makkelijk worden geschreven. BCNF kan in som- 
mige gevallen te vergaand zijn, als de gegevens maar zelden worden bijgewerkt en 
als inconsequente gegevens makkelijk kunnen worden gecorrigeerd door bedrijfs- 
processen. Het is dan beter de originele, niet-genormaliseerde tabellen te gebruiken. 
De door meerwaardige afhankelijkheden veroorzaakte problemen zijn zo groot dat 
deze altijd moeten worden verwijderd. 

Read-only-databases worden gebruikt voor applicaties voor rapportage, query’s en 
datamining. Het maken van dergelijke databases is een taak die vaak aan beginners 
wordt toegekend. Het normaliseren is minder gewenst als er read-only-databases 
worden ontworpen. Genormaliseerde invoergegevens zullen vaak gedenormali- 
seerd moeten worden door ze samen te voegen en het samengevoegde resultaat op 
te slaan. Soms zijn er ook veel kopieën van dezelfde gegevens opgeslagen in tabellen 
die zijn aangepast voor specifieke applicaties. 
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Erzijn vier problemen die veel voorkomen tijdens het maken van databases op basis 
van bestaande gegevens. Het ontwerp met meer kolommen voor meer waarden be- 
paalt vooraf hoeveel herhaalde waarden er kunnen zijn. Elk van deze waarden wordt 
dan in een eigen kolom opgeslagen. Een dergelijk ontwerp beperkt het aantal toe- 
gestane items en resulteert in onhandige SQL-query’s. Meer waarden in een eigen 
tabel plaatsen levert een beter ontwerp op. 

Er kunnen inconsequente waarden optreden als de gegevens afkomstig zijn van 
verschillende gebruikers en applicaties. Zoals in dit hoofdstuk toegelicht, kunnen 
inconsequente waarden worden opgespoord met SQL-statements. Een nullwaarde 
is niet hetzelfde als een lege waarde. Van een nullwaarde is niet bekend wat zij be- 
tekent. Een nullwaarde is een probleem vanwege de dubbelzinnigheid. Zij kan bete- 
kenen dat een waarde niet toepasselijk is, niet bekend is of dat de waarde bekend is 
maar nog niet in de database is ingevoerd. 

De kolom met algemene opmerkingen is een kolom die voor diverse doelein- 
den wordt gebruikt. Deze kolom verzamelt gegevens op een breedsprakige, incon- 
sequente manier. Dergelijke kolommen zijn vooral problematisch als ze gegevens 
bevatten die nodig zijn voor een externe sleutel. Maar zelfs als dat niet het geval is, 
zullen ze vaak gegevens bevatten voor diverse kolommen. Er zijn geen geautomati- 


seerde oplossingen mogelijk en het corrigeren van dit probleem vereist veel geduld 
en werk. 


Belangrijke termen 


COUNT(*) nullwaarde 
denormaliseren SELECT * 
DROP TOP 
INSERT 

Oefeningen 


IR 


Vat het uitgangspunt van dit hoofdstuk samen. 
p), 


Welke stappen moet je nemen om de structuur en de inhoud van de tabellen te 
beoordelen als je een verzameling tabellen krijgt> 


Laat SQL:statements zien voor het tellen van het aantal rijen en het weergeven 


van de eerste vijftien rijen van een tabel met de naam RETAIL ORDER. 
4. _ Stel dat je de volgende twee tabellen krijgt: 


AFDELING (Afdelingsnaam, BudgetCode) 
WERKNEMER (Werknemernummer, Naam, E-mail, Afdelingsnaam) 


en dat je concludeert dat WERKNEMER Afdelingsnaam een externe sleutel is 
naar AFDELING Afdelingsnaam. Laat SQL zien waarmee te bepalen is of aan de 
volgende referentiële integriteitsvoorwaarde is voldaan: 
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WERKNEMER. Afdelingsnaam moet bestaan in AFDELING.Afdelingsnaam 


Vat samen welke verschillen er bestaan in de principes voor het ontwerpen van 
updatable databases en van read-only-databases. 

Beschrijf twee voordelen van genormaliseerde tabellen. 

Waarom zeggen we dat het aantal dubbele gegevens wordt verminderd? Waar- 
om zeggen we niet dat dubbele gegevens worden geëlimineerd? 

Hoe kunnen we stellen dat de mogelijkheid voor het optreden van inconsequen- 
te gegevens is geëlimineerd als we het aantal dubbele gegevens alleen hebben 
verminderd? 

Noem een nadeel van genormaliseerde tabellen. 

Stel dat je de volgende tabel krijgt: 


WERKNEMER AFDELING 
(Werknemernummer, Naam, E-mail, Afdelingsnaam, Budgetcode) 


en dat je deze tabel wilt omzetten in de volgende twee tabellen: 
WERKNEMER (Werknemernummer, Naam, E-mail, Afdelingsnaam) 
en 

AFDELING (Afdelingsnaam, Budgetcode) 


Laat SQL-statements zien voor het vullen van de tabellen WERKNEMER en AF- 
DELING met gegevens uit WERKNEMER AFDELING. 


Welke reden is er om postcodes niet in BCNF te brengen? 

Beschrijf een andere situatie dan die met postcodes waarin je ervoor zou kiezen 
tabellen niet in BCNF te brengen. Rechtvaardig de beslissing om geen gebruik 
te maken van BCNF. 

In welke situaties zou je volgens dit boek ervoor kiezen meerwaardige afhanke- 
lijkheden niet uit een relatie te verwijderen? 

Vergelijk de moeilijkheidsgraad van het schrijven van subquery’s en joins met 
de moeilijkheidsgraad van het afrekenen met door meerwaardige afhankelijk- 
heden veroorzaakte anomalieën. 

Beschrijf drie gebruiksdoelen van een read-only-database. 

Welke invloed heeft het feit dat een read-only-database nooit wordt bijgewerkt 
op de redenen voor het normaliseren? 

Hoe overtuigend is het argument dat het normaliseren de opslagruimte voor be- 
standen vermindert voor read-only-databases? 

Wat is denormaliseren? 

Stel dat je de tabellen AFDELING en WERKNEMER uit vraag 1o krijgt en dat je ge- 
vraagd wordt deze te denormaliseren tot de relatie WERKNEMER AFDELING. 
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Laat het ontwerp van de relatie WERKNEMER AFDELING zien. Geef een SQL- 
statement voor het vullen van gegevens in deze tabel. 


20. Vat de redenen samen voor het maken van aangepaste tabellen met dubbele 
gegevens. 


21. Waarom worden aangepaste tabellen met dubbele gegevens niet gebruikt voor 
updatable databases? 


22. Noem vier ontwerpproblemen die vaak voorkomen bij het maken van databases 
op basis van bestaande gegevens. 


23. Bedenk een eigen voorbeeld van een tabel met meer kolommen voor meer 
waarden. 


24. Leg uit wat de problemen zijn met het voorbeeld dat je als antwoord op de vorige 
vraag gaf. 


25. Laat zien hoe je de relatie uit het antwoord op vraag 23 kunt representeren met 
twee tabellen. 


26. Laat zien hoe de tabellen uit het antwoord op vraag 25 de problemen oplossen 
die je in vraag 24 benoemde. 
27. Geef uitleg bij de volgende bewering: ‘Het probleem met meer kolommen voor 


meer waarden is gewoon een andere vorm van meerwaardige afhankelijkheid.’ 
Leg uit waarom dat zo is. 


„ Geef manieren aan waarop inconsequente gegevens ontstaan. 


„ Waarom leveren inconsequente gegevens vooral veel problemen op in externe 
sleutels? 


. Beschrijf twee manieren voor het identificeren van inconsequente waarden. Is 


het zeker dat deze technieken alle inconsequente waarden vinden? Welke an- 
dere stap kun je nemen? 


31. Wat is een nullwaarde? 
32. Waarin verschilt een nullwaarde van een lege waarde? 
33. Noem drie interpretaties van nullwaarden. Gebruik een voorbeeld in je antwoord. 


34. Laat SQL zien voor het bepalen van het aantal nullwaarden in de kolom Naam 
van de tabel WERKNEMER. 


Beschrijf het probleem met een kolom met algemene opmerkingen. 


Geef een voorbeeld waarbij de kolom met algemene opmerkingen het moeilijk 
kan maken waarden voor een externe sleutel te krijgen. 


35. 
36. 


37. Geef een voorbeeld waarbij de kolom met algemene opmerkingen problemen 


veroorzaakt als er meer waarden worden opgeslagen in dezelfde kolom. Hoe los 
je dat probleem op? 


38. Waarom moet je oppassen voor kolommen met algemene opmerkingen? 


Projectvragen 
Sportclub Speed bezit drie sportclubgebouwen in Groningen. Elk clubgebouw 


biedt een brede keuze aan trainingsapparatuur, zalen voor gewichtheffen en zalen 
voor yoga en andere bewegingslessen. Speed biedt een lidmaatschap aan voor drie 
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maanden en een lidmaatschap voor een jaar. Leden kunnen gebruikmaken van de 
voorzieningen in elk van de drie clubgebouwen. 

Speed houdt een rooster bij van persoonlijke trainers, die als onafhankelijke con- 
sultants werken. Goedgekeurde trainers kunnen afspraken met cliënten inplannen 
bij de clubgebouwen van Speed, mits de cliënt lid is van de club. De trainers geven 
ook les in yoga, pilates en andere lessen. Neem bij het beantwoorden van de volgen- 
de vragen aan dat je de volgende drie tabellen hebt gekregen (PT staat voor persoon- 
lijke trainer): 


PT_SESSIE (Trainer, Telefoon, E-mail, Honorarium, Cliëntnaam, 
CliëntTelefoon, CliëntE-mail, Datum, Tijd) 
CLUB_ LIDMAATSCHAP (Cliëntnummer, Cliëntnaam, Telefoon, E-mail, 
SoortLidmaatschap, Einddatum, Straat, 
Plaats, Provincie, Postcode) 
LES (Lesnaam, Trainer, Begindatum, Einddatum, Tijd, 
DagVanWeek, Prijs) 


39. Identificeer mogelijke meerwaardige afhankelijkheden in deze tabellen. 

40. Identificeer mogelijke functionele afhankelijkheden in deze tabellen. 

41. Ga na of elke tabel in BCNF of in 4NF is. Noem de aannames. 

42. Wijzig elk van deze tabellen zodat ze allemaal in BCNF en 4NF zijn. Gebruik de 
aannames die je in het antwoord op vraag 41 gaf. 

43. Gebruik deze tabellen en je aannames en maak een ontwerp voor een updatable 
database. 

44. Voeg een tabel toe aan het antwoord op vraag 43 die het Speed mogelijk maakt 
leden aan specifieke lessen toe te kennen. Neem een kolom BetaaldBedrag op 
in de nieuwe tabel. 

45. Maak een ontwerp voor een read-only-database die de volgende eisen moet kun- 
nen ondersteunen: 

a. Het ontwerp moet het trainers mogelijk maken zeker te stellen dat hun 
cliënten lid zijn van de club. 

b. Het ontwerp moet het de club mogelijk maken te beoordelen hoe populair 
de diverse trainers zijn. 

c. Het ontwerp moet het de trainers mogelijk maken te bepalen of ze dezelfde 
cliënt bijstaan. 

d. Het ontwerp moet het trainers die lessen geven mogelijk maken te bepalen 
of de deelnemers aan hun lessen daar ook voor hebben betaald. 


Marcia’s Chemische Reiniging 


Marcia is bezig met het maken van databases die haar moeten helpen de werk- 
zaamheden en het beheer van haar bedrijf te ondersteunen. Zij en haar staf hebben 
het afgelopen jaar een kassaregistratiesysteem gebruikt dat de volgende gegevens 
verzamelt: 
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SALE (InvoiceNumber, Dateln, DateQut, Total, Phone, FirstName, 
LastName) 


Het komt jammer genoeg voor dat niet alle gegevens worden ingevoerd als het druk 
is. Er komen dan ook veel nullwaarden voor in Phone, FirstName en LastName. 
Soms is maar een van deze drie null, soms zijn dat er twee en soms zijn ze alle drie 
null. InvoiceNumber, Dateln en Total zijn nooit null. Er komen een paar nullwaar- 
den voor in DateOut. Als het erg druk is, worden telefoonnummers en namen soms 
ook verkeerd ingevoerd. 
Marcia heeft bij een plaatselijk handelsbedrijf een lijst met postadressen aange- 
schaft om haar te helpen bij het maken van haar database. Deze lijst bevat de vol- 
gende gegevens: 


HOUSEHOLD (Phone, FirstName, LastName, Street, City, State, 
Zip, Apartment) 


Er zijn soms meer namen voor een telefoonnummer. De primaire sleutel is daarom 
de samenstelling (Phone, FirstName, LastName). Er komen geen nullwaarden voor 
in Phone, FirstName en LastName, maar er komen wel een paar nullwaarden voor 
in de adresgegevens. 


Er zijn veel namen in SALE die niet in HOUSEHOLD voorkomen en er zijn veel 
namen in HOUSEHOLD die niet in SALE voorkomen. 


A. Ontwerp een updatable database voor het opslaan van klantengegevens en ver- 
koopgegevens. Leg uit hoe er moet worden omgegaan met het probleem van 
ontbrekende gegevens. Leg uit hoe er moet worden omgegaan met het pro: 
bleem van onjuiste telefoon- en naamgegevens. 

B. 


Ontwerp een read-only-database voor het opslaan van klantengegevens en ver- 
koopgegevens. Leg uit hoe er moet worden omgegaan met het probleem van 
ontbrekende gegevens. Leg uit hoe er moet worden omgegaan met het pro: 
bleem van onjuiste telefoon- en naamgegevens. 


Importbedrijf Morgan 


Phillip Morgan reist regelmatig naar diverse landen om in te kopen. Hij houdt tij- 
dens deze reizen notities bij over de dingen die hij koopt. Hij noteert ook basisge- 
gevens over het verschepen van deze dingen. Hij heeft een universiteitsstudente 
aangenomen als assistente en zij heeft zijn notities omgezet in de spreadsheets uit 
Figuur 4-10. Dit zijn alleen voorbeeldgegevens. Phillip heeft in de loop van de jaren 
honderden dingen gekocht, die in tientallen verschillende ladingen zijn verscheept. 

Phillip wil het informatietijdperk betreden en heeft daarom besloten een data- 
base te ontwikkelen voor zijn inventaris. Hij wil bijhouden welke dingen hij heeft 
gekocht en hoe ze zijn verscheept. Na verloop van tijd wil hij ook klanten- en ver- 
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koopgegevens gaan registreren. Hij heeft je gevraagd om te beginnen een database 
te maken voor de gegevens uit Figuur 4-11. 


A 8 c o € F G H " LI \ 

1_Shipmentumber Shipper Phone Contact _ From Departure Arrival Contents InsuredValue / 
QE deneng set, large bureau, 

2 49100300 Wordende 800-1234567 Jose Pmippnes 5/5/2003 67/11/1599 porcelan lamps $27 500 
Mascellaneous knen large masks, 

3 485955 intenatsonal €00-123-8338 Martyn Sengapore 6/2/2009 14 zetting Willow design china s7 500, 
Woven goeds antigee leather í 

4 84830 Wordwde 500-1234567 Jose Peru 71372003 7722/2009 chars 
Large bureau. brass lamps. wlow | 

5 399400 Intenatcnai 800-123-8898 Manlyn Singaporeee 8/5/2009 9711/2009 design serang dishes $18.000 

6 

7 

5 

3 kem Date City Store Salesperson Price 

10 Wiliow Serang Dishes 71/15/2009 Singapore Jade Antiques Swee Lai $4.509 

u Large bureau 1/31/2009 Singapere Eastern Sales Jeremey 9.500 ! 

12 Brass lamps 71/20/2009 Singapore Jade Antiques Mr James $1,200 

13 QE Dining Set 4/1/20039 Manda E Treasures Gracelie s14 300 


Figuur 4-11 Spreadsheets van Importbedrijf Morgan 


A. Volg de in Figuur 4-1 beschreven procedure voor het beoordelen van deze gege- 
vens. Maak een lijst met meerwaardige afhankelijkheden, functionele afhanke- 
lijkheden, kandidaat-sleutels, primaire sleutels en externe sleutels. Vermeld de 


aannames. 

B. Maak een lijst met vragen die je aan Phillip wilt stellen om de aannames te 
controleren. 

C. Maak zo nodig tabellen om eventuele meerwaardige afhankelijkheden te 
elimineren. 


D. De relatie tussen verschepingsgegevens en itemgegevens zou af te leiden zijn 
door de waarden uit de cellen onder From te vergelijken met de waarden uit de 
cellen onder City. Beschrijf twee problemen met deze strategie. 

E. Beschrijf een wijziging in deze spreadsheet die de relatie verscheping/item wel 
uitdrukt. 

F. Neem aan dat Phillip een updatable database wil maken op basis van deze ge- 
gevens. Ontwerp tabellen waarvan je denkt dat ze toepasselijk zijn. Noem alle 
referentiële integriteitsvoorwaarden. 

G. Neem aan dat Phillip een read-only-database wil maken op basis van deze ge- 
gevens. Ontwerp tabellen waarvan je denkt dat ze toepasselijk zijn. Noem alle 
referentiële integriteitsvoorwaarden. 

H. Hebben deze gegevens het probleem met meer kolommen voor meer waarden? 
Zo ja, hoe ga je daarmee om? 

1. Hebben deze gegevens het probleem met inconsequente gegevens? Zo ja, hoe 
ga je daarmee om? 

J. Hebben deze gegevens door nullwaarden veroorzaakte problemen? Zo ja, hoe 
ga je daarmee om? 

K. Hebben deze gegevens het probleem met een kolom met algemene opmerkin- 
gen? Zo ja, hoe ga je daarmee om? 
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Hoofdstuk 5 
Gegevens modelleren met het 
entiteit-relatiemodel 


We gaan in de komende twee hoofdstukken in op het ontwerpen van databases bij het 
ontwikkelen van nieuwe informatiesystemen. Dergelijke databases worden ontworpen 
door eisen te analyseren en een datamodel te maken van een database die aan die 
eisen voldoet. Het datamodel wordt dan omgezet in een databaseontwerp. 

Dit hoofdstuk bespreekt het maken van datamodellen met behulp van het entiteit- 
relatiediagram — de populairste techniek voor het modelleren. Dit hoofdstuk bestaat uit 
drie hoofddelen. We leggen eerst de belangrijkste elementen van het entiteit-relatie- 
model uit en beschrijven in het kort diverse variaties op dat model. We lichten daarna 
het proces van het modelleren van gegevens toe aan de hand van het voorbeeld van 
een kleine database van een universiteit. Je moet echter eerst weten welk doel een 
datamodel heeft. 
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51 Het doel van een datamodel 


Een datamodel is een bouwplan of een blauwdruk voor een databaseontwerp. Denk 
bij wijze van analogie eens na over het bouwen van een woning of een appartemen- 
tengebouw. De aannemer ging niet te werk door domweg een stapel hout te kopen, 
de betonwagens te bestellen en aan de slag te gaan. In plaats daarvan stelde een 
architect plannen en blauwdrukken op voor het gebouw, lang voordat de eigenlijke 
bouw ervan begon. Werd er in het planningstadium bepaald dat een bepaalde kamer 
te groot of te klein was, dan kon de blauwdruk simpel worden aangepast door een 
paar lijnen uit te gummen en opnieuw te tekenen. Zou echter een dergelijke wijzi- 
ging nodig zijn nadat het gebouw is neergezet, dan zouden de muren, de elektrische 
leidingen, water- en gasleidingen, enzovoort allemaal moeten worden afgebroken 
en opnieuw opgebouwd. Dat zou veel tijd en geld kosten. Het plan kan makkelijker, 
sneller en eenvoudiger worden gewijzigd dan een voltooid gebouw. 

Hetzelfde argument gaat op voor datamodellen en databases. Een relatie is tij- 
dens het stadium van de datamodellering te wijzigen door simpelweg het diagram 
en de gerelateerde documentatie aan te passen. Het wordt echter veel moeilijker een 
relatie te wijzigen als de database en de applicaties eenmaal voltooid zijn. Er moe- 
ten gegevens naar de nieuwe indeling worden gemigreerd, SQL-statements moeten 
worden aangepast, formulieren en rapporten moeten worden gewijzigd, enzovoort. 


5,2 Het entiteit-relatiemodel 


In de loop van de jaren zijn er tientallen hulpmiddelen en technieken bedacht voor 
het maken van datamodellen. Deze omvatten het hiërarchische datamodel, het net- 
werk-datamodel, het ANSI/SPARC-datamodel, het entiteit-relatiemodel, het seman- 
tische-objectenmodel en nog veel meer. Het entiteit-relatiemodel heeft zich echter 
tot het standaarddatamodel ontwikkeld en we gaan in dit hoofdstuk alleen op dat 
datamodel in. 

Het entiteit-relatiedatamodel (E-R-model) werd in 1976 voor het eerst gepubli- 
ceerd door Peter Chen.' Chen schetste de basiselementen van het model. Het uitge- 
breide E-R-model* ontstond doordat subtypen aan het E-R-model werden toegevoegd 
(subtypen bespreken we later). Het uitgebreide E-R-model is wat de meeste mensen 


tegenwoordig bedoelen als ze de term E-R-model gebruiken. Dat is ook het model dat 
we in dit boek gebruiken. 


5.2.1 Entiteiten 


Een entiteit is iets wat de gebruikers willen volgen. Het is iets wat makkelijk is te 
identificeren in de werkomgeving van de gebruikers. Voorbeelden van entiteiten zijn 


1 Peter P. Chen (januari 1976), ‘The Entity-Relationship Model — Towards a Unified View of Data” 
ACM Transactions on Database Systems, pagina 9-36. 


2 TJ. Teorey, D. Yang en J.P. Fry (juni 1986), ‘A Logical Design Methodology for Relational Databases 
Using the Extended Entity-Relationship Model’, ACM Computing Surveys, pagina 197-222. 
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werknemer Marie Langeland, klant 12345, verkoopbon rooo, verkoper Walter Smit 
en product A4200. Entiteiten van een gegeven type worden gegroepeerd tot een enti- 
teitenklasse. De entiteitenklasse WERKNEMER is dus de verzameling van alle werk- 
nemerentiteiten. Entiteitenklassen schrijven we in dit boek geheel in hoofdletters. 

Het is belangrijk dat je begrijpt wat het verschil is tussen een entiteitenklasse 
en een instantie van een entiteit. Een entiteitenklasse is een verzameling entiteiten 
en wordt beschreven door de structuur van de entiteiten in die klasse. Een instantie 
van een entiteitenklasse is een afzonderlijk voorkomende, specifieke entiteit, zoals 
klant 12345. Een entiteitenklasse kent normaal gesproken veel instanties van entitei- 
ten. De entiteitenklasse KLANT heeft bijvoorbeeld veel instanties — één voor elke in 
de database gerepresenteerde klant. Je ziet de entiteitenklasse KLANT en twee in- 
stanties van deze klasse in Figuur 5-1. 


KLANT | 

| Klantnummer 

| Klantnaam 

Straat 
Plaats 
Provincie 
Postcode 
Contactnaam 

[Email | 
1234 99890 
Ajax Fabricage Gebr. Janssen 
lepenlaan 23 Achterstraat 434 
Utrecht Amsterdam 
Utrecht Noord-Holland 
3245 DX 1024 AC 
P. Swart Frans Bakels 
p_s@ajax.com frans@geja.com 


Figuur 5-1 De entiteit KLANT en twee instanties daarvan 


5.2.2 Attributen 

Entiteiten hebben attributen die hun eigenschappen beschrijven. Voorbeelden van 
attributen zijn Werknemernummer, Werknemernaam, Telefoon en E-mail. Attri- 
buten noteren we in dit boek in een combinatie van hoofd- en kleine letters. Het 
E-R-model neemt aan dat alle instanties van een gegeven entiteitenklasse dezelfde 
attributen hebben. 

Figuur 5-2 toont twee verschillende manieren voor het weergeven van de attribu- 
ten van een entiteit. Figuur s-2(a) toont attributen in ovalen die via een lijn met de 
entiteit zijn verbonden. Deze stijl werd gebruikt in het originele E-R-model, voordat 
er softwareproducten voor datamodellering verschenen. Figuur 5s-2(b) toont de blok- 
stijl zoals de huidige softwareproducten voor datamodellering deze gebruiken. 
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Werknemernaam 


WERKNEMER 


Werknemernaam 


Werknemernummer 


WERKNEMER elsloen 
E-mail 
DatumAangenomen |, 


DatumReview 


DatumReview 
DatumAangenomen 


(a) Attributen in ovalen 


(b) Attributen in een 
rechthoek 


Figuur 5-2 Varianten voor het weergeven van attributen in entiteitendiagrammen 


52.3 Identifiers 


Instanties van entiteiten hebben identifiers — attributen die instanties van de entiteit 
benoemen of identificeren. Instanties van WERKNEMER kunnen bijvoorbeeld wor- 
den geïdentificeerd door Werknemernummer, Sofinummer of Werknemernaam. 
Instanties van WERKNEMER worden waarschijnlijk niet geïdentificeerd door at- 
tributen zoals Salaris of DatumAangenomen, want dergelijke attributen worden 
normaliter niet gebruikt in een identificerende rol. Klanten kunnen worden geïden- 
äficeerd door Klantnummer of Klantnaam en bestellingen door Bestelnummer. 

De identifier van een instantie van een entiteit bestaat uit een of meer attributen 
van de entiteit. ldentifiers die uit twee of meer attributen bestaan, noemen we samen- 
gestelde identifiers. Voorbeelden daarvan zijn (Netnummer, Abonneenummer), 
(Projectnaam, Taaknaam) en (Voornaam, Achternaam, DatumAangenomen). 


Opmerking 


Merk de overeenkomst op tussen identifiers en sleutels. De term identifier wordt gebruikt in een 
datamodel, de term sleutel wordt gebruikt in een databaseontwerp. Entiteiten hebben dus identifiers. 


ee (of relaties) hebben sleutels. 1dentifiers vervullen dezelfde rol voor entiteiten als sleutels voor 
tabellen. 


Entiteiten kunnen in drie niveaus aan detail worden weergegeven in een datamodel. 
De entiteit zal soms samen met al haar attributen worden weergegeven. De identi. 
fier van de entiteit wordt in dergelijke gevallen boven aan de entiteit getoond, met 
een horizontale streep eronder. Je ziet dat in Figuur 5-3(a). Een Eren niveau aan 
detail kan de diagrammen. van een groot datamodel onoverzichtelijk en onhandel. 
baar maken. Het entiteitendiagram wordt in dergelijke gevallen vereenvoudigd door 


alleen de identifier te tonen, zoals in Figuur 5-3(b), of door alleen de naam van de 
entiteit weer te geven in een rechthoek, zoals je dat in Figuur 5-3(c) ziet 
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WERKNEMER 
Werknemernummer | WERKNEMER 


Werknemernaam _ | Werknemernummer |) 


WERKNEMER 


Î 


Telefoon 


E-mail | 
DatumAangenomen |, 
DatumReview 


(a) Entiteit met (b) Entiteit met alleen (c) Entiteit zonder 
alle attributen het identifier-attribuut attributen 


Figuur 5-3 Variaties van het weergaveniveau voor entiteiten en attributen 


Deze drie technieken worden allemaal gebruikt in de praktijk — de kortste vorm uit 
Figuur 5-3(c) wordt gebruikt voor het weergeven van een overzicht van de entiteiten 
en de algehele relaties tussen die entiteiten. De meer gedetailleerde weergave uit 
Figuur 5-3(a) wordt vaak gebruikt tijdens het ontwerpen van databases. De meeste 
softwareproducten voor datamodellering kunnen alle drie niveaus genereren. 


5.2.4 Relaties 

Entiteiten kunnen met elkaar verbonden zijn via relaties. Het E-R-model omvat rela- 
tieklassen en instanties van relaties Relatieklassen zijn verbindingen tussen entitei- 
tenklassen. Instanties van relaties zijn verbindingen tussen instanties van entiteiten. 
Relaties konden in het originele E-R-model attributen hebben. Relaties hebben in de 
recente versie van het E-R-model geen attributen. 

Er worden namen aan de relaties gegeven die de aard van deze relaties omschrij- 
ven. De relatie Kwalificatie uit Figuur 5-4 toont welke vaardigheden elke werknemer 
heeft. De relatie ‘Werkt aan’ laat zien welke combinaties van cliënten, architecten en 
projecten er zijn gemaakt. We vermijden in dit hoofdstuk onnodige ingewikkeld- 
heid door de namen van relaties alleen te tonen als er dubbelzinnigheden kunnen 
optreden. 


Opmerking 

Wees je ervan bewust dat je een relatie kunt benoemen vanuit de positie van elk van de entiteiten — of 
van beide entiteiten tegelijk. Je zou de relatie tussen WERKNEMER en AFDELING bijvoorbeeld ‘Afdeling 
bestaat uit’ kunnen noemen, of ‘Werknemer werkt in’ — of je kunt beide namen gebruiken, gescheiden 
door een schuine streep (Afdeling bestaat uit / werknemer werkt in). De namen van relaties moeten 
worden weergegeven als er twee verschillende relaties zijn tussen dezelfde twee entiteiten. 


Een relatieklasse kan twee of meer entiteitenklassen omvatten. Het aantal entitei- 
tenklassen in de relatie noemen we de graad van de relatie. De relatie Kwalificatie 
uit Figuur 5-4(a) is van de tweede graad, want deze omvat twee entiteitenklassen: 


3 We zullen het woord instantie soms om redenen van bondigheid weglaten als de context duidelijk 
maakt dat het om een instantie van een entiteit gaat en niet om een entiteitenklasse 
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(a) Voorbeeld van een binaire relatie 


VAARDIGHEID 


ee 


Kwalificatie 


(b) Voorbeeld van een ternaire relatie 
Werkt aan 


CLIENT 


ARCHITECT | 


ROJECT 


Figuur 5-4 Binaire versus ternaire relaties 


WERKNEMER en VAARDIGHEID. De relatie ‘Werkt aan’ is van de derde graad, 
want deze omvat drie entiteitenklassen: CLIËNT, ARCHITECT en PROJECT. Re- 
laties van de tweede graad noemen we binaire relaties. Relaties van de derde graad 
worden op een soortgelijke manier ternaire relaties genoemd. 


Relaties van een hogere graad dan twee worden tijdens het omzetten van een da- 


tamodel in een relationeel ontwerp behandeld als combinaties van binaire relaties. 
Alle softwareproducten voor datamodellering eisen dat je relaties uitdrukt als binaire 
relaties. De relatie uit Figuur 5-4(b) bijvoorbeeld wordt ontleed in drie binaire relaties 


(Zie je welke?). Zoals je in paragraaf 6.7 kunt zien, vereist het omzetten van som- 
mige niet-binaire relaties wat extra werk. 
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Opmerking 

Je vraagt je nu misschien af wat het verschil is tussen een entiteit en een tabel - het lijkt tot dusver alsof 
dat verschillende termen zijn voor hetzelfde onderwerp. Het principiële verschil tussen een entiteit en 
een tabel is dot je een relatie tussen entiteiten kunt uitdrukken zonder externe sleutels te gebruiken. Je 
kunt een relatie opgeven met het E-R-model door simpelweg een verbindingslijn tussen twee entiteiten 
te tekenen. je hoeft je daarbij niet druk te maken over primaire en externe sleutels, referentiële 
integriteitsvoorwaarden, enzovoort. Je bent immers bezig met logische datamodellering en niet met 

het ontwerpen van een fysieke database. Mocht je op dergelijke details willen ingaan: de meeste 
softwareproducten voor het modelleren van gegevens staan dat toe, ze vereisen dat echter niet. 

Je kunt daardoor vooral in de eerste stadia van een project makkelijker met entiteiten werken dan met 
tabellen, als de entiteiten en relaties nog in ontwikkeling en nog veranderlijk zijn. Je kunt relaties tussen 
entiteiten weergeven voordat je zelfs maar weet wat hun identifiers zijn. je kunt bijvoorbeeld bepalen 
dat een AFDELING aan veel WERKNEMERS ís gerelateerd, voordat je de attributen van WERKNEMER of 
AFDELING kent. Dat maakt het je mogelijk algemeen te beginnen en langzamerhand steeds meer 

details in te vullen. Identificeer eerst de entiteiten. Denk daarna na over relaties en bepaal ten slotte de 
attributen. 


GEGEVENS MODELLEREN MET HET ENTITEIT-RELATIEMODEL 


Relaties worden in het entiteit-relatiemodel geclassificeerd op hun kardinaliteit 
(waarmee gewoon het aantal wordt bedoeld). De maximumkardinaliteit is het maxi- 
male aantal instanties van een entiteit dat aan een instantie van een relatie kan deel- 
nemen. De minimumkardinaliteit is het minimale aantal instanties van een entiteit 
dat aan een instantie van een relatie moet deelnemen. 


5.2.5 Maximumkardinaliteit 

De maximumkardinaliteit wordt in Figuur 5-5 getoond in de ruit die de relatie weer- 
geeft. De drie onderdelen van deze figuur tonen de drie basis-maximumkardinali- 
teiten van het E-R-model. Figuur 5-5(a) laat een één-op-één-relatie (r:r-relatie) zien. 


(a) Eén-op-éénrelatie 


WERKNEMER F 


Werknemer Identiteit 


(b) Eén-op-veel-relatie 


WERKNEMER COMPUTER 


Toegekende Computer 


(c) Veel-op-veel-relatie 


VAARDIGHEID 


WERKNEMER 


Kwalificatie 


Figuur 5-5 Drie soorten maximumkardinaliteit 


Een instantie van het ene soort entiteit kan in een r:1-relatie aan maximaal één in- 
stantie van het andere soort entiteit zijn gekoppeld. De relatie Werknemer. Identi- 
teit uit Figuur 5-5(a) koppelt één instantie van WERKNEMER aan één instantie van 
BADGE. Dit diagram geeft aan dat geen enkele werknemer meer dan één badge 
heeft, en dat geen enkele badge aan meer dan één werknemer is toegekend. 

De relatie Toegekende_ Computer uit Figuur 5-5(b) illustreert een één-op-veel (of 
r:N)-relatie. Een enkele instantie van WERKNEMER kan hier met veel instanties 
van COMPUTER zijn verbonden, maar een instantie van COMPUTER is altijd aan 
maar één instantie van WERKNEMER gekoppeld. Dit diagram geeft aan dat een 
werknemer met meer computers kan werken, maar dat elke computer aan maar één 
werknemer is toegekend. 

De posities van de r en de N zijn van belang. De 1 staat aan de kant van de lijn 
naar WERKNEMER. Dat betekent dat de 1 naar de WERKNEMER=-kant van de relatie 
verwijst. De N staat aan de kant van de lijn naar COMPUTER, wat betekent dat de N 
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naar de COMPUTER-kant van de relatie verwijst. Zouden de r en de N worden om- 
gedraaid en zou de relatie als N:1 worden geschreven, dan zou elke WERKNEMER 
maar één COMPUTER hebben en zou een enkele COMPUTER aan veel WERK- 
NEMERs zijn toegekend. 

De Engelse termen parent en child worden soms gebruikt bij het bespreken van 
één-op-veel-relaties. De parent is de entiteit aan de één-kant van de relatie en de child 
is de entiteit aan de veel-kant van de relatie. AFDELING is dus de parent en WERK- 
NEMER de child in een r:N-relatie tussen AFDELING en WERKNEMER. 

Figuur 5-s(c) toont een veel-op-veel (of N:M)-relatie. De relatie Kwalificatie geeft 
aan dat een instantie van WERKNEMER veel instanties van VAARDIGHEID kan 
hebben en dat een instantie van VAARDIGHEID met veel instanties van WERK- 
NEMER verbonden kan zijn. Deze relatie documenteert het feit dat een werknemer 
veel vaardigheden kan hebben en dat er veel werknemers kunnen zijn die dezelfde 
vaardigheid hebben. 

Studenten vragen zich soms af waarom we veel-op-veel-relaties als N:M schrij- 
ven, en niet als N:N of M:M. We doen dat omdat de kardinaliteit in de ene rich- 
ting kan verschillen van de kardinaliteit in de andere richting. Met andere woorden: 
N hoeft niet gelijk te zijn aan M in een N:M-relatie. Een bepaalde WERKNEMER 
kan bijvoorbeeld vijf vaardigheden hebben, terwijl een van die vaardigheden bij drie 


werknemers kan horen. De schrijfwijze N:M benadrukt het feit dat de kardinaliteiten 
verschillend kunnen zijn. 


Opmerking 

Relaties zoals die in Figuur 5-5 worden soms ook wel HEEFT-EEN-relaties genoemd. Deze term wordt 
gebruikt omdat elke instantie van een entiteit een relatie heeft met een instantie van een tweede 
entiteit. Een werknemer heeft een badge, een badge heeft een werknemer. Is de maximumkardinaliteit 
groter dan 1, dan heeft elke entiteit een verzameling andere entiteiten. Een werknemer heeft 


bijvoorbeeld een reeks vaardigheden en elke vaardigheid heeft een verzameling van werknemers die 
deze vaardigheid hebben. 


De maximumkardinaliteit is soms een vaststaand getal. Het maximumaantal spelers 
in een voetbalteam is bijvoorbeeld rr. De maximumkardinaliteit tussen TEAM en 
SPELER zou in dat geval ingevuld worden met rr, in plaats van de meer algemene N. 


5.2.6 Minimumkardinaliteit 

De minimumkardinaliteit is het aantal instanties van een entiteit dat aan een relatie 
moet deelnemen. Het minimum zal over het algemeen o of 1 zijn. Het getal o bete- 
kent dat deelname aan de relatie optioneel is. Het getal 1 betekent dat er minstens 
één instantie van de entiteit aan de relatie moet deelnemen. Een optionele relatie 
wordt in E-R-diagrammen aangegeven met een rondje in de relatielijn. Een verplich- 
te relatie wordt aangegeven met een kruisstreepje in de relatielijn. 


GEGEVENS MOOELLEREN MET HET ENTITEI-RELATIEMODEL 
(a) Deze relatie is verplicht-tot-verplicht (M-M) 


WERKNEMER | SO BADGE _ | 


Werknemer Identiteit 


(b) Deze relatie is optioneel-tot-optioneel (O-O) 


WERKNEMER Ho > O4 COMPUTER | 


Toegekende _ Computer 


(c) Deze relatie is optioneel-tot-verplicht (O-M) 


WERKNEMER |o Ge) HH VAARDIGHEID |: 


Kwalificatie 


Figuur 5-6 Voorbeelden van de minimumkardinaliteit 


Figuur 5-6 helpt je deze termen beter te begrijpen. De kruisstrepen in de relatie 
Werknemer Identiteit geven aan dat een WERKNEMER verplicht is een BADGE te 
hebben en dat een BADGE aan een WERKNEMER moet zijn toegekend. Een derge- 
lijke relatie heet verplicht-tot-verplicht, of op zijn Engels, mandatory-to-mandatory 
(kortweg M-M), omdat er aan beide kanten entiteiten vereist zijn. De volledige speci- 
ficatie van de relatie Werknemer. ldentiteit is dat dit een 1:1-, M-M-relatie is. 

De beide rondjes in Figuur 5-6(b) geven aan dat de relatie Toegekende_Computer 
optioneel-tot-optioneel (O-O) is. Dat betekent dat een WERKNEMER geen COMPU- 
TER hoeft te hebben en dat een COMPUTER niet aan een WERKNEMER hoeft te 
zijn toegekend. De relatie Toegekende_Computer is dus een r:N-, O-O-relatie. 

De combinatie van een rondje en een kruisstreep in Figuur 5-6(c) geeft ten slot- 
te een relatie aan die optioneel-tot-verplicht is. Er moet in dit geval minstens een 
VAARDIGHEID aan een WERKNEMER zijn toegekend, maar er hoeft niet nood- 
zakelijkerwijs een WERKNEMER aan een VAARDIGHEID te zijn toegekend. De 
volledige specificatie voor de relatie Kwalificatie is dus dat dit een N:M-, O-M-relatie 
is. De plaatsing van het rondje en de kruisstreep is belangrijk. Het feit dat het rondje 
aan de kant van WERKNEMER staat, betekent dat de werknemer optioneel is in de 
relatie. 

De vierde optie, M-O, wordt niet in Figuur 5-6 getoond. Kwalificatie wordt echter 
een M-O-relatie als we het rondje en de kruisstreep in Figuur 5-6(c) omdraaien. Een 
WERKNEMER hoeft in dat geval geen VAARDIGHEID te hebben, maar elke VAAR- 
DIGHEID moet dan aan minstens één WERKNEMER zijn toegekend. 

Net als bij de maximumkardinaliteit kan de minimumkardinaliteit in zeldzame 
gevallen ook weer een specifiek getal zijn. Zou je bijvoorbeeld de relatie tussen PER- 
SOON en HUWELIJK willen weergeven, dan zou de minimumkardinaliteit 2:O zijn. 
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Opmerking 

Het is studenten soms niet duidelijk welke entiteit optioneel is en welke verplicht, als ze diagrammen 
interpreteren zoals die uit Figuur 5-6(c). Je kunt dat makkelijk zien door je voor te stellen dat je op de 
tuit in het midden van de relatielijn staat. Stel je voor dat je in de richting van een van de entiteiten kijkt. 
Zie je een rondje in die richting, dan is deze entiteit optioneel. Zie je een kruisstreep, dan is deze entiteit 
vereist. Als je in Figuur 5-6(c) op de ruit staat en naar VAARDIGHEID kijkt, zie je een kruisstreep. Dat 
betekent dat VAARDIGHEID vereist is in deze relatie. 


5.2.7 Entiteit-relatiediagrammen en de versies daarvan 

De diagrammen in Figuur 5-5 en Figuur 5-6 worden soms ook wel entiteit-relatiedia- 
grammen genoemd. Het originele E-R-model bepaalde dat dergelijke diagrammen 
relaties in ruiten tonen, entiteiten in rechthoeken en attributen in daarmee verbon- 
den ovalen. Je ziet dat in Figuur 5-2. Je zult misschien nog steeds voorbeelden van 
dergelijke E-R-diagrammen tegenkomen. Het is dan ook belangrijk dat je ze kunt 
interpreteren. 

Er zijn echter twee redenen waarom deze originele notatie tegenwoordig nog 
maar zelden wordt gebruikt. Er zijn om te beginnen een aantal verschillende versies 
van het E-R-model, die met verschillende symbolen werken. Softwareproducten voor 
datamodellering gebruiken bovendien andere technieken. ERwin van Computer As- 
sociate gebruikt bijvoorbeeld een andere verzameling symbolen dan Microsoft Visio. 


5.2.8 Varianten van het E-R-model 


Er zijn tegenwoordig minstens drie versies van het E-R-model in gebruik. Een van 
deze versies, die het Information Engineering- of IE-model wordt genoemd, werd in 
19go ontwikkeld door James Martin. Dit model gebruikt kraaienpoten om de veel- 
kant van een relatie aan te geven. Het wordt daarom ook wel het kraaienpootmodel 
genoemd. Dit model is makkelijk te begrijpen en we gebruiken het daarom in de rest 
van dit boek. 

Het Amerikaanse National Institute of Standards and Technology verkondigde 
in 1993 een andere versie van het E-R-model tot een (Amerikaanse) nationale stan- 
daard. Deze versie heet IDEFIX, of Integrated Definition 1, Extended.+ Deze stan- 
daard omvat de basisideeën van het E-R-model maar gebruikt andere grafische 
symbolen. Dit model is erg moeilijk te begrijpen en ingewikkeld in het gebruik. Het 
wordt toch vaak gebruikt omdat het nu eenmaal een belangrijke, wereldwijd erkende 
standaard is. Het kan dan ook van belang voor je blijken te zijn. We beschrijven de 
grondbeginselen van het IDEFrX-model daarom in bijlage B. 

Om het nog ingewikkelder te maken, werd het E-R-model ook geadopteerd door 
een nieuwe modelleertaal die de Unified Modeling Language of UML wordt ge- 


noemd. Deze taal introduceerde zijn eigen symbolen en gaf een objectgeoriënteerde 
draai aan het model. De UML-notatie wordt samengevat in bijlage C. 


PSE 


4 Integrated Definition for Information Modeling (IDEF1X), Federal Information Processing Standards 
Publication 184, 1993: 
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Opmerking 

Er zijn niet alleen verschillen tussen de versies van het E-R-model, er zijn ook verschillen tussen 
verschillende softwareproducten waarmee je de modellen kunt maken. Twee producten die het 
kraaienpootmodel implementeren, kunnen dat op verschillende manieren doen. Het resultaat is nogal 
verwarrend. Als je een diagram van een datamodel maakt, moet je daarom niet alleen kennis hebben 
van de versie van het E-R-model dat je gebruikt, maar ook van de eigenaardigheden van de software die 
je gebruikt. 


5.2.9 E-R-diagrammen met het kraaienpootmodel 

Kijk eens naar Figuur 5-7, die twee versies laat zien van een één-op-veel, optioneel-tot- 
verplichte relatie. Figuur 5-7(a) toont de versie van het originele E-R-model. Figuur 
5-7(b) laat het kraaienpootmodel zien. De relatie wordt aangegeven met een stippel- 
lijn. Aan de veel-kant van de relatie staat een kraaienpootsymbool. 


AFDELING HO GND) WERKNEMER 


(a) Originele E-R-model 


AFDELING Oi nn FF WERKNEMER 


(b) Versie van het kraaienpootmodel 


Figuur 5-7 Versies van een één-op-veel, optioneel-tot-verplichte relatie 


Het kraaienpootmodel maakt gebruik van de notatie in Figuur 5-8 om de kardinali- 
teit van een relatie aan te geven. Het symbool dat het dichtst bij de entiteit staat, geeft 
de maximumkardinaliteit aan, het andere symbool de minimumkardinaliteit. Een 
kruisstreepje geeft 1 aan (en dus verplicht), een rondje geeft o aan (en dus optioneel). 
Een kraaienpoot geeft ‘veel’ aan. 

Het diagram in Figuur 5-7(b) betekent dus dat een AFDELING een of meer 
WERKNEMERS heeft (de symbolen duiden op veel en op verplicht), en dat een 
WERKNEMER tot nul of één AFDELING behoort (de symbolen duiden op 1 en op 
optioneel). 

Figuur 5-9 laat twee versies van een N:M, optioneel-tot-verplichte relatie zien. Een 
WERKNEMER moet ten minste één VAARDIGHEID hebben en kan er verschei- 
dene hebben. Omgekeerd kan een VAARDIGHEID bij geen enkele WERKNEMER 
horen, maar eventueel bij meer dan één. Figuur 5-9(b) toont de minimumkardinali- 
teiten met behulp van de notatie uit Figuur 5-8. 
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Symbool 


Betekenis 


Verplicht-Een 


Verplicht-Veel 


Optioneel-Een 


Optioneel-Veel 


Figuur 5-8 Notatie kraaienpootmodel 


WERKNEMER [0 (a) VAARDIGHEID 


(a) Originele E-R-model 


| WERKNEMER Do Á VAARDIGHEID 


(b) Versie van het kraaienpootmodel 


Figuur 5-9 Versies van een veel-op-veel, optioneel-tot-verplichte relatie 


We gebruiken in de rest van dit boek, afgezien van bijlage B en C, het kraaienpoot- 
model voor E-R-diagrammen. Wees je er echter van bewust dat andere producten op 
een iets andere manier gebruik kunnen maken van het rondje, de kruisstreep en de 
kraaienpoot. Als je een andere tool gebruikt, relateer je de datamodellen uit dit boek 
aan de tool die je gebruikt. Het uitvoeren van dergelijke aanpassingen is een goede 


oefening. 
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Opmerking 
Er zijn verscheidene modelleerproducten die je kunt proberen, elk met zijn eigenaardigheden. 


Een daarvan is ERwin. Je kunt de ERwin Data Modeler Community Edition, die geschikt is voor 
studiedoeleinden, downloaden van www.ca.com/us/software-trials.aspx. 


Microsoft Visio is ook een mogelijkheid. je kunt een probeerversie downloaden van 
http://office.microsoft.com/en-us/visio/default.aspx. 


Een andere mogelijkheid is de MySQL Workbench van Sun Microsystems. Je kunt deze downloaden van 
http://dev.mysql.com/downloads/workbench/5.1.html. 


5.2.10 Sterke en zwakke entiteiten 

Een sterke entiteit (strong entity) is een entiteit die iets representeert dat op 
zichzelf kan bestaan. PERSOON is bijvoorbeeld een sterke identiteit — we be- 
schouwen mensen als zelfstandige individuen. Hetzelfde geldt voor een AUTO. 
Een zwakke entiteit (weak entity) is een entiteit waarvan het bestaan afhankelijk is 
van de aanwezigheid van een andere entiteit. In de volgende paragrafen zie je daar 
voorbeelden van. 


5.2.11 ID-afhankelijke entiteiten 

Het E-R-model omvat een speciaal type entiteit, dat we een ID-afhankelijke entiteit 
noemen. Een [D-afhankelijke entiteit is een entiteit waarvan de identifier de identi- 
fier van een andere entiteit omvat. Zoals je weet uit paragraaf 5.2.3 zijn identifiers de 
attributen die instanties van de entiteit benoemen of identificeren. 

Denk bijvoorbeeld eens na over een studentenflat: een gebouw met daarin appar- 
tementen. De identifier voor een dergelijke entiteit is een samenstelling: (Gebouw- 
naam, Appartementnummer). Gebouwnaam is de identifier van het hele gebouw. 
Alleen het Appartementnummer is niet voldoende om iemand te kunnen vertellen 
waar je woont. Als je zegt dat je in appartement nummer 5 woont, zal men moeten 
vragen in welk gebouw. 

Je ziet drie verschillende ID-afhankelijke entiteiten in Figuur 5-10. Naast APPAR- 
TEMENT is er de entiteit REPRODUCTIE, die ID-afhankelijk is van SCHILDERIJ, 
en de entiteit ONDERZOEK, die ID-afhankelijk is van PATIËNT. 

De ID-afhankelijke entiteit kan in elk van deze gevallen niet bestaan, tenzij de pa- 
rent (de entiteit waar deze entiteit van afhankelijk is) ook bestaat. De maximumkar- 
dinaliteit van de ID-afhankelijke entiteit tot de parent is dus altijd r. 

Het hangt af van de door de applicatie gestelde eisen of de parent ook verplicht 
een ID-afhankelijke entiteit heeft. APPARTEMENT en REPRODUCTIE zijn in 
Figuur 5-1o beide optioneel, maar ONDERZOEK is verplicht. Deze eisen volgen uit 
de aard van de applicatie en zijn niet het resultaat van enigerlei logische eisen. 

Zoals je in het E-R-model van Figuur 5-ro kunt zien, gebruiken we een rechthoek 
met afgeronde hoeken om een ID-afhankelijke entiteit te tekenen. Bovendien teke- 
nen we een doorgetrokken lijn tussen de ID-afhankelijke entiteit en haar parent. Dit 
type relatie heet een identificerende relatie. 
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GEBOUW 


GebouwNaam 


Straat 

Plaats 
Provincie/staat 
Postcode/zipcode 


APPARTEMENT 


AppartementNummer 
GebouwNaam 


AantalSlaapkamers 
AantalBadkamers 
HuurPerMaand 


(a) APPARTEMENT is 
ID-afhankelijk van 
GEBOUW 


SCHILDERIJ 


SchilderijNaam 


Beschrijving 
Afmetingen 
Jaar 

Artiest 


( 
REPRODUCTIE 


PATIËNT 


PatiëntNaam 


Telefoon 
E-mail 


IN 


ONDERZOEK 


KopieNummer 
SchilderijNaam 


Toestand 
Koopprijs 
DatumGekocht 


(b) REPRODUCTIE is 
ID-afhankelijk van 
SCHILDERIJ 


Datum 
PatiëntNummer 


Gewicht 
Lengte 
Bloeddruk 


(c) ONDERZOEK is 
ID-afhankelijk 
van PATIENT 


Figuur 5-10 Voorbeelden van ID-afhankelijke entiteiten 


Een relatie die met een stippellijn wordt getekend, zoals in Figuur 5-7, stelt een ge- 
wone, niet-identificerende relatie voor. In deze relatie zijn geen ID-afhankelijke 
entiteiten. 

ID-afhankelijke entiteiten leggen beperkingen op aan de manier waarop de op 
basis daarvan opgestelde database wordt verwerkt. De rij die de parent-entiteit repre- 
senteert, moet namelijk eerst gemaakt worden, voordat er een ID-afhankelijke child- 
rij kan worden gemaakt. Alle child-rijen moeten bovendien mee worden verwijderd 
als de parent-rij wordt verwijderd. 

ID-afhankelijke entiteiten komen veel voor. Een ander voorbeeld is de entiteit 
VERSIE in de relatie tussen PRODUCT en VERSIE, waarbij PRODUCT een soft- 
wareproduct is en VERSIE een releaseversie van dat product is. De identifier van 
PRODUCT is Productnaam en de identifier van VERSIE is (Productnaam, Release- 
nummer). Een ander voorbeeld is EDITIE in de relatie tussen LEERBOEK en EDI- 
TIE. De identifier van LEERBOEK is Titel en de identifier van EDITIE is (Titel, 
Editienummer). 


52.12 Niet-ID-afhankelijke zwakke entiteiten 

Alle ID-afhankelijke entiteiten zijn zwak. Maar het omgekeerde hoeft niet het geval 
te zijn. Een zwakke entiteit hoeft niet ID-afhankelijk te zijn. Kijk eens naar de enti- 
teiten MODEL en AUTO in Figuur 5-11. MODEL representeert het ontwerp van een 
bepaald model auto en AUTO representeert een specifieke auto. 
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Het zal duidelijk zijn dat er geen auto kan bestaan die geen model heeft — het model 
is het ontwerp van de auto. AUTO is dus een zwakke entiteit. 

In Figuur 5-11(a) krijgt elke auto een uniek serienummer. De identifier van AUTO 
bestaat dus uit (Fabrikant, Model) en is dus ID-afhankelijk van MODEL. 

We kunnen echter, zoals in Figuur 5-11(b), AUTO een identifier geven die niet af- 
hankelijk is van Fabrikant en Model. Dat kan met het VIN, het Vehicle Identification 
Number, een uniek nummer voor elk voertuig. Omdat AUTO nu een identifier van 
zichzelf heeft, is hij niet meer ID-afhankelijk. De meeste modelleersoftware is niet in 
staat om zwakke niet-ID-afhankelijke relaties weer te geven. Daarom hebben we dit 
type relatie door middel van een opmerking in Figuur 5-11(b) aangegeven. 


MODEL MODEL 


Fabrikant 
Model 


Farikant 
Model 


Beschrijving 
AantalPassagiers 


Beschrijving 
AantalPassagiers 
BagageCapaciteit 


Opmerking: AUTO is 
& een zwakke, maar 


AUTO niet ID-afhankelijke entiteit. 


Kleur 
FabricageDatum 


Kleur 
FabricageDatum 
Kosten 
Verkoopprijs 
DatumVerkocht 


Kosten 
Verkoopprijs 
DatumVerkocht 


(a) (b) 
Figuur 5-11 Een ID-afhankelijke (en dus zwakke) entiteit en een zwakke niet-ID-afhankelijke entiteit 


Het feit dat een entiteit een vereiste relatie tot een andere entiteit heeft, betekent niet 
dat deze entiteit zwak is. Een STUDENT kan verplicht zijn een ADVISEUR te heb- 
ben, maar het bestaan van STUDENT is niet afhankelijk van het bestaan van AD- 
VISEUR. Dat houdt in dat STUDENT geen zwakke entiteit is. Het bestaan van een 
entiteit moet logisch gezien vereisen dat een andere entiteit bestaat, wil deze zwak 
zijn. Een ONDERZOEK moet een PATIËNT hebben, een AUTO moet een MODEL 
hebben en een AFSPRAAK moet een CLIËNT hebben. Dergelijke entiteiten zijn al- 
tijd zwak. 
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Figuur 5-12 vat de kenmerken samen van ID-afhankelijke en zwakke entiteiten. 


Samenvatting van ID-afhankelijke en zwakke entiteiten 4 

Een ID-afhankelijke entiteit is een entiteit waarvan de identifier de identifier van een andere entiteit omvat. | 
Er worden identificerende relaties gebruikt voor het representeren van 1D-afhankelijke entiteiten. | 
Een zwakke entiteit is een entiteit waarvan het bestaan afhankelijk is van een andere entiteit. | 
Alle 1D-afhankelijke entiteiten zijn zwak. _ ME es he 
Sommige entiteiten zijn zwak maar niet 1D-afhankelijk. Deze worden met tools voor datamodellering 
weergegeven als niet-identificerende relaties, met een afzonderlijke documentatie die aangeeft dat ze 
zwak zijn. 


Figuur 5-12 Samenvatting van ID-afhankelijke en zwakke entiteiten 


5.2.13 Subtype-entiteiten 

Het uitgebreide E-R-model introduceerde het idee van subtypen. Een subtype-en- 

üteit is een speciaal geval van een andere entiteit, die het supertype daarvan wordt 
genoemd. Studenten kunnen bijvoorbeeld worden geclassificeerd als DOCTORAAL 
en POSTDOCTORAAL. In dit geval is STUDENT het supertype en DOCTORAAL 
en POSTDOCTORAAL zijn de subtypen. Een student kan bijvoorbeeld ook geclas- 
sificeerd worden als een eerstejaars-, tweedejaars-, derdejaars- of vierdejaarsstudent. 
STUDENT is in dat geval het supertype en EERSTEJAARS, TWEEDEJAARS, DER- 
DEJAARS en VIERDEJAARS zijn de subtypen. 


STUDENT STUDENT 


StudentlD [StudentlD___ 
Achternaam 
Voornaam 


Achternaam 
Voornaam 
IsPostDoc 


DOCTORAAL POSTDOCTORAAL KLIMCLUB ZEILCLUB 


(StudentiD ___) (StudentD ____\) (Studemip (StudentiD ___}| 
EindexGem DoctoraalGem DatumBetaald DatumBetaald 
ToelatingsScore GemResultaat BedragBetaald BedragBetaald 


(a) Exclusieve subtypen met een (b) Inclusieve subtypen 
discriminatorattribuut 


Figuur 5-13 Voorbeelden van subtypen 


Zoals je in Figuur 5-13 ziet, gebruiken we een cirkel met een streep eronder om de 
relatie supertype-subtype aan te geven. Je kunt dit interpreteren als een optionele (de 
cirkel) 1:1-relatie (de streep). We gebruiken een doorgetrokken lijn om de ID-afhan- 
kelijkheid aan te geven, want elk subtype is ID-afhankelijk van zijn supertype. Merk 
op dat in dit geval geen van de symbolen uit Figuur 5-8 wordt gebruikt. 
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Een attribuut van het supertype kan in sommige gevallen aangeven welk van de sub- 
typen toepasselijk is voor een bepaalde instantie. Zo'n attribuut heet een discrimi- 
nator. In Figuur 5-13(a) is het attribuut IsPostDoc de discriminator. Dit attribuut kan 
alleen de waarde Ja of Nee hebben, en bepaalt daarmee of de student in kwestie een 
postdoctoraalstudent is of niet. In het E-R-diagram plaats je de naam van de discri- 
minator naast subtypesymbool. 

Niet alle supertypen hebben een discriminator. Is er geen discriminator, dan 
moet het onderscheid voor het juiste subtype in de applicatie worden gemaakt. 

Subtypen kunnen exclusief of inclusief zijn. Voor een exclusief subtype geldt dat 
een instantie van een supertype aan ten hoogste één subtype is gerelateerd. De in- 
stantie van een supertype van een inclusief subtype kan aan een of meer subtypen 
zijn gerelateerd. In Figuur 5-13(a) betekent de X in de cirkel dat de subtypen exclu- 
sief zijn. Dat wil zeggen dat een STUDENT een DOCTORAALstudent of een POST- 
DOCTORAALstudent is, maar niet beide. 

Figuur 5-13(b) laat zien dat een STUDENT lid kan zijn van de zeilclub of van de 
klimclub, of van beide. Het zijn inclusieve subtypen. Merk op dat er geen X in de cir- 
kel staat. Inclusieve subtypen hebben geen discriminator, want een instantie van het 
supertype kan aan meer dan één subtype zijn gerelateerd. 


Opmerking 

Relaties die supertypen met subtypen verbinden, worden IS-EEN-relaties genoemd, omdat een subtype 
dezelfde entiteit is als het supertype. De identifier van een supertype en de identifiers van alle subtypen 
daarvan moeten dan ook identiek zijn - ze representeren allemaal verschillende aspecten van dezelfde 
entiteit. Vergelijk deze term met HEEFT-EEN-relaties, waarin een entiteit een relatie naar een andere 
entiteit heeft, maar de identiteit (en de identifier) van deze twee entiteiten verschillend is. 


De belangrijkste (en volgens sommigen de enige) reden voor het maken van sub- 
typen in een datamodel is om niet-toepasselijke nullwaarden te vermijden. Docto- 
raalstudenten moeten het doctoraalexamen nog doen, dus is bij hen de waarde van 
de datum van dat examen NULL, in tegenstelling tot bij postdoctoraalstudenten, 
omdat zij het examen al gedaan hebben. Zulke nullwaarden kun je vermijden door 
subtypen te creëren. 


5.2.14 Samenvatting kraaienpootnotatie 

De elementen van het entiteit-relatiemodel worden samengevat in Figuur 5-14. De 
identifier en de attributen worden alleen in het eerste voorbeeld weergegeven. Merk 
op dat een relatie tot een parent-entiteit optioneel kan zijn voor r:1 en r:N niet-identi- 
ficerende relaties. De parent is altijd vereist voor identificerende relaties. 
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Entiteit AFDELING, AfdelingNaam is de identifier, BudgetCode en Kantoornummer zijn 
attributen. 


1:1 niet-identificerende relatie. A is gerelateerd aan nul of een B, B is gerelateerd aan 
precies één A, De relatie wordt weergegeven met een stippellijn. 


1:N niet-identificerende relatie. A is gerelateerd aan een of veel B's. B is gerelateerd aan 
nul of een A. De relatie wordt weergegeven met een stippellijn. 


N:M niet-identificerende relatie. A is gerelateerd aan nul of meer B's. B is gerelateerd aan 
een of meer A's. De relatie wordt weergegeven met een stippellijn. 


1:N identificerende relatie. A is gerelateerd aan nul, een of veel B's. B is gerelateerd aan 
precies één A. De relatie wordt weergegeven met een doorgetrokken lijn. De child moet 
bij een identificerende relatie altijd aan precies één parent zijn gerelateerd. De parent kan 
aan nul, een of veel children zijn gerelateerd. 

A is een supertype, C en D zijn exclusieve subtypen. De discriminator wordt hier niet 
getoond. Relaties worden weergegeven met een doorgetrokken lijn. | 


A is een supertype, C en D zijn inclusieve subtypen. Relaties worden weergegeven met een | 
doorgetrokken lijn. | 


Figuur 5-14 Samenvatting kraaienpootnotatie 


5,3 Associatierelaties 


Een associatierelatie is een ID-afhankelijke relatie die op een N:M sterke relatie lijkt. 
Bekijk het rapport van een prijsopgave door verschillende bedrijven van een aantal 
producten in Figuur 5-15. Prijs is geen attribuut van een BEDRIJF en het is ook geen 
attribuut van een ONDERDEEL. Het is een attribuut van de combinatie van een BE- 
DRIJF en een ONDERDEEL. 


Prijsopgave onderdelen 


nderde rdeelNaa, Ver! p, v ob” Bedrijfsnaam Plaats Land Prijs 
1000 Hardhouten paal €22,00 100 200 
Bristol Systems Manchestor Engeland € 14,00 
ERS Systems Vancouver Canada € 12,50 
Forest Supplies Denver Amerika € 15,50 
2000 Garagekachel €1.750,00 3 4 
Bristol Systems Manchester Engeland € 950,00 
ERS Systems Vancouver Canada € 875,00 
Kyoto Importers Kyoto Japan € 1.100,00 
Forest Supplies Denver Amerika € 915,00 
3000 Opbergkast € 55,00 7 3 
Ajax Fabricage Rotterdam Nederland € 37,50 
Forest Supplies Denver Amerika € 42,50 


Figuur 5-15 Een voorbeeldrapport dat een associatiepatroon toont 
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Figuur 5-16 toont het toepasselijke datamodel voor een dergelijk geval. Er is hier een 
derde entiteit met de naam PRIJSOPGAVE toegevoegd, om het attribuut Prijs op te 
slaan. De identifier van PRIJSOPGAVE is de combinatie van Onderdeelnummer en 
Bedrijfsnaam. Merk op dat Onderdeelnummer de identifier is van ONDERDEEL en 
dat Bedrijfsnaam de identifier is van BEDRIJF. PRIJSOPGAVE is dus ID-afhankelijk 
van ONDERDEEL en van BEDRIJF. 

Dat betekent dat de relaties tussen ONDERDEEL en PRIJSOPGAVE en tussen 
BEDRIJF en PRIJSOPGAVE beide identificerend zijn in Figuur 5-16. Dat feit wordt 
in de figuur aangegeven door de doorgetrokken lijnen. 


ONDERDEEL BEDRIJF 


Onderdeelnummer Bedrijfsnaam 


Onderdeelnaam 
Verkoopprijs 
AantalBestellen 
AantalVoorraad 


Plaats 
Land 
Volume 


kk 


PRIJSOPGAVE 


Onderdeelnummer 
Bedrijfsnaam 


Prijs 


Figuur 5-16 Het associatiepatroon voor het rapport uit Figuur 5-15 


De parent-entiteiten zijn vereist, zoals dat bij alle identificerende relaties het geval is. 
Dat houdt in dat de minimumkardinaliteit van PRIJSOPGAVE naar ONDERDEEL 
en de minimumkardinaliteit van PRIJSOPGAVE naar BEDRIJF beide een zijn. De 
minimumkardinaliteit in de andere richting wordt bepaald door de eisen die een be- 
drijf stelt. Een ONDERDEEL moet in dit geval een PRIJSOPGAVE hebben, maar een 
BEDRIJF hoeft geen PRIJSOPGAVE te hebben. 

Er kunnen associaties optreden tussen meer dan twee soorten entiteiten. Figuur 
5-17 laat bijvoorbeeld een datamodel zien voor het toekennen van een bepaalde klant 
aan een bepaalde architect voor een bepaald project. Het attribuut van deze toeken- 
ning is UrenGewerkt. Dit datamodel laat zien hoe de drieledige relatie uit Figuur 
5-4(b) kan worden gemodelleerd als een combinatie van drie binaire relaties. 
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CLIËNT ARCHITECT 


Cliëntnaam 


Cliëntnaam 
Architectnaam 
Projectnaam 


Figuur 5-17 Een model voor het associatiepatroon voor de drieledige relatie Toekenning uit Figuur 5-4 


Relaties met meerwaardige attributen 

Attributen mogen maar één waarde hebben volgens het E-R-model zoals dat tegen- 
woordig wordt gebruikt; Heeft de entiteit KLANT de attributen Telefoonnummer en 
Contactpersoon, dan kan een klant hoogstens één waarde hebben voor het telefoon- 
nummer en hoogstens één waarde voor de contactpersoon. 

Figuur 5-18 toont het datamodel. We maken een ID-afhankelijke entiteit TELE- 
FOON die het attribuut Telefoonnummer bevat, in plaats van Telefoonnummer als 
een attribuut van KLANT op te nemen. De relatie van KLANT tot TELEFOON is r:N, 
wat betekent dat een bedrijf meer telefoonnummers kan hebben. De identifier van 


TELEFOON omvat zowel Telefoonnummer als Bedrijfsnaam, omdat het een ID-af- 
hankelijke entiteit is. 


5.4 Het proces van het modelleren van gegevens 


Tijdens het proces van het modelleren van gegevens analyseert het ontwikkelings- 
team de eisen van gebruikers en maakt het een datamodel op basis van formulieren, 
rapporten, gegevensbronnen en gesprekken met gebruikers. Dit is altijd een itera- 
tief (herhaaldelijk) proces — er wordt een model gemaakt op basis van een formulier 
of een rapport. Dit model wordt vervolgens aangevuld en aangepast, terwijl er meer 
formulieren en rapporten worden geanalyseerd. 


nn 

5 Het oorspronkelijke E-R-model stond meerwaardige attributen toe. In de loop van de tijd zijn der- 
gelijke attributen in onbruik geraakt en tegenwoordig gaan de meeste mensen ervan uit dat het 
E-R-model enkelvoudige attributen vereist. In dit boek gaan wij daar ook van uit. 
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BEDRIJF 


Bedrijfsnaam 


Plaats 
Land 
Volume 


TELEFOON 


Figuur 5-18 Datamodel 


Er wordt regelmatig met de gebruikers gesproken om hun meer informatie te vra- 
gen, zoals de informatie die nodig is voor het beoordelen van de minimumkardi- 
naliteit. De gebruikers controleren en valideren het datamodel ook. Zoals eerder 
uitgelegd, moeten er misschien prototypen worden gemaakt die constructies uit het 
datamodel demonstreren. 

Om je een idee te geven van de iteratieve aard van de datamodellering, bekijken 
we de ontwikkeling van een eenvoudig datamodel voor een universiteit. Probeer tij- 
dens het lezen van dit voorbeeld te volgen hoe het model evolueert naarmate er 
steeds meer eisen worden geanalyseerd. 


Opmerking 

Het grootste datamodel waaraan ik, de auteur van dit boek, heb gewerkt, was voor het logistieke 
systeem van het Amerikaanse leger. Dat model omvatte meer dan vijfhonderd verschillende soorten 
entiteiten. Een team van zeven mensen had meer dan een jaar nodig voor het ontwerpen, documenteren 
en valideren van het model. De analyse van een nieuwe eis gaf in sommige gevallen aan dat we ons 

het model verkeerd hadden voorgesteld, waarna we het werk van dagen moesten overdoen. Het meest 
ingewikkelde aspect van het project was het overzien van de complexiteit. Er was een globaal begrip van 
het model nodig om te weten welke entiteiten aan welke andere entiteiten waren gerelateerd, of een 
entiteit al was gedefinieerd en of een nieuwe entiteit sterk, zwak of een subtype was. Ons geheugen 
alleen hielp ons daar niet veel bij. Een in juli gemaakte entiteit kon een subtype zijn van een van de 
honderden entiteiten die we eerder, in februari, hadden gemaakt. We maakten gebruik van allerlei 
administratieve hulpmiddelen om het model te beheren. Houd dat voorbeeld in gedachten terwijl je leest 
hoe het datamodel voor de universiteit van Leiderhoven wordt ontwikkeld. 


Stel dat de administratie van de hypothetische universiteit van Leiderhoven een da- 
tabase wil maken voor het bijhouden van faculteiten, vakgroepen, professoren en 
studenten. Een datamodelleringteam heeft daartoe een reeks rapporten verzameld 
als onderdeel van het proces van het bepalen van de eisen. In de volgende paragrafen 
analyseren we deze rapporten om een datamodel te produceren. - 
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5,4.1 Het faculteitrapport 

Het voorbeeldrapport in Figuur 5-19 gaat over een bepaalde faculteit, namelijk de 
economische faculteit. Dit voorbeeld is een enkele instantie van dit rapport — de uni- 
versiteit van Leiderhoven heeft soortgelijke rapporten over andere faculteiten, zoals 
de technische faculteit en de faculteit sociale wetenschappen. Het datamodellering- 
team moet voldoende voorbeelden van een formulier verzamelen om een represen- 
tatief voorbeeld van alle faculteitrapporten te krijgen. Neem aan dat het rapport in 
Figuur 5-19 representatief is. 


Economische Faculteit 
Marie B. Jetkens, Decaan 


Adres: 
Telefoon 232-1187 Gebouw B, Kamer 100 


Vakgroep 


Voorzitter Telefoon Afstuderenden 


Boekhouden Jackson, Seymour P. 232-1841 318 
Financiering HeuTeng, Susan 232-1414 211 

Info-systemen __Brammer, Nathaniel D. 236-0011 247 
Bestuurskunde Tuttle, Christine A. 236-9988 184 
Statistiek Barnes, Jack T. 236-1184 212 


Figuur 5-19 Een voorbeeld van een faculteitrapport 


FACULTEIT VAKGROEP 
Faculteitnaam 


Vakgroepnaam 


Decaannaam 
Telefoon 
Gebouw 
Kamer 


Voorzitter 
Telefoon 
AantalAfstuderenden 


Figuur 5-20 Het datamodel op basis van het faculteitrapport 


We vinden tijdens het onderzoeken van dit rapport gegevens die specifiek zijn voor 
de faculteit, zoals de naam, de decaan, het telefoonnummer en het campus-adres. 
We vinden daarnaast ook gegevens over elke vakgroep binnen de faculteit. Deze ge- 
gevens suggereren dat het datamodel de entiteiten FACULTEIT en VAKGROEP 
moet omvatten, met een relatie daartussen. Je ziet dat in Figuur 5-20. 

De relatie in figuur Figuur 5-20 is niet-identificerend. We gebruiken deze relatie 
omdat VAKGROEP niet-ID-afhankelijk is en omdat een VAKGROEP logisch gezien 
onafhankelijk is van een FACULTEIT. We kunnen niet uit het rapport opmaken of 
een vakgroep tot veel faculteiten kan behoren. We moeten met de gebruikers spre- 
ken of andere formulieren en rapporten bekijken om deze vraag te beantwoorden. 

Neem aan dat we van de gebruikers te weten zijn gekomen dat een vakgroep al- 
tijd bij een enkele faculteit hoort en dat de relatie van FACULTEIT tot VAKGROEP 
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dus r:N is. Het rapport uit Figuur 5-19 laat niet zien wat de minimumkardinaliteiten 
zijn. We zullen ook dat weer aan de gebruikers moeten vragen. Neem aan dat zij ons 
vertellen dat een faculteit minstens één vakgroep moet hebben en dat een vakgroep 
altijd tot precies één faculteit behoort. 


5.4.2 Het rapport Vakgroep /Professor 
Het vakgroeprapport in Figuur 5-21 bevat gegevens over de vakgroep en een lijst van 
professoren van deze vakgroep. 


Vakgroep Informatiesystemen 
Economische Faculteit 


Voorzitter: Brammer, Nico D. 

Telefoon: 236-0011 

Adres: Gebouw Sociale Wetenschappen, 
Kamer 213 


Professor Kantoor 
Jansen, Paul Soc. Wetenschappen, 219 232-7713 
Petersen, Mary Soc. Wetenschappen, 308 232-5791 
Wu, Elizabeth Soc. Wetenschappen, 207 232-9112 


Telefoon 


Figuur 5-21 Voorbeeld van een vakgroeprapport 


Het rapport bevat ook gegevens over het campus-adres van de vakgroep, die niet 
voorkomen in de entiteit VAKGROEP uit Figuur 5-20. We moeten deze gegevens dus 
toevoegen. Je ziet dat in Figuur 5-22(a). Dat is gebruikelijk voor het proces van het 
modelleren van gegevens. Met andere woorden: entiteiten en relaties worden aange- 
past terwijl er meer formulieren, rapporten en andere eisen worden geanalyseerd. 

In Figuur 5-22(a) is ook de relatie tussen VAKGROEP en PROFESSOR toege- 
voegd. We modelleren deze relatie in eerste instantie als N:M, want een professor 
kan meerdere aanstellingen hebben. Het datamodelleringteam zal verder onderzoek 
moeten doen naar de eisen om te bepalen of meerdere aanstellingen zijn toegestaan. 
Is dat niet het geval, dan kan de relatie worden geherdefinieerd als niet-identifice- 
rend, r:N, zoals je dat in Figuur 5-22(b) ziet. 

Een andere mogelijkheid wat betreft de N:M-relatie is dat een bepaald attribuut 
over de combinatie van een professor en een vakgroep ontbreekt. Stel dat het team 
een rapport vindt van de universiteit van Leiderhoven dat de titel en de arbeidsvoor- 
waarden beschrijft voor elke professor in elke vakgroep. Figuur 5-22(c) toont een 
entiteit voor een dergelijk rapport, met de naam BENOEMING. BENOEMING is ID- 
afhankelijk van zowel VAKGROEP als PROFESSOR. 

Een voorzitter is een professor. Het model is daarom nog verder te verbeteren 
door de Voorzittergegevens uit VAKGROEP te verwijderen en deze te vervangen 
door een voorzitterrelatie. We deden dat in Figuur 5-22(d). De PROFESSOR is de 
parent-entiteit in de relatie Zit voor/Voorgezeten door. Een professor kan de voorzit- 
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ter zijn van nul vakgroepen of van één vakgroep, en een vakgroep moet precies één 
professor hebben als voorzitter. 

Het attribuut Voorzitter is niet meer nodig in VAKGROEP vanwege de relatie Zit 
voor/Voorgezeten door. Dit attribuut wordt daarom verwijderd. Een voorzitter heeft 
zijn of haar kantoor normaliter in het vakgroepkantoor — Telefoon, Gebouw en Ka- 
mer in VAKGROEP kunnen in dat geval duplicaten zijn van Telefoon, Gebouw en 
Kamer in PROFESSOR. Dat betekent dat we Telefoon, Gebouw en Kamer mogelijk 
uit VAKGROEP kunnen verwijderen. Maar een professor heeft wellicht een ander 
telefoonnummer dan het officiële telefoonnummer van de vakgroep. Hij of zij heeft 
misschien ook een kantoor buiten het vakgroepkantoor. We laten Telefoon, Gebouw 
en Kamer daarom in VAKGROEP staan. 


5.4.3 Het rapport Vakgroep /Hoofdvak 

Figuur 5-23 toont een rapport van een vakgroep en de studenten die een hoofdvak in 
die afdeling hebben. Het rapport geeft aan dat er een nieuwe entiteit met de naam 
STUDENT nodig is. 


Overzicht afstudeerders 
Vakgroep Informatiesystemen 


Voorzitter: Brammer, Nico D. Telefoon: 2236-0011 
Naam afstudeerder Studentnummer Telefoon 
Jackson, Robin R. 12345 237-8713 

Litjens, Fred J. 48127 237-8713 
Madink, Jasine A. 37512 237-8713 


Figuur 5-23 Tweede vakgroeprapport 


De relatie tussen VAKGROEP en STUDENT die je in Figuur 5-24 ziet is niet-iden- 
tificerend, want studenten zijn niet ID-afhankelijk van vakgroepen. We kunnen de 
minimumkardinaliteit niet bepalen op basis van het rapport, maar we nemen aan 
dat gesprekken met gebruikers duidelijk hebben gemaakt dat een STUDENT een 
HOOFDVAK moet hebben, maar dat een HOOFDVAK geen studenten hoeft te heb- 
ben. We nemen op basis van de inhoud van dit rapport bovendien de attributen 
Studentnummer, Studentnaam en Telefoon op in STUDENT. 

Er zijn twee subtiele punten in deze interpretatie van het rapport uit Figuur 5-23. 
Merk ten eerste op dat de Naam afstudeerder is veranderd in Studentnaam, toen dit 
attribuut in STUDENT werd opgenomen. We hebben dat gedaan omdat Student- 
naam meer algemeen is. Naam afstudeerder heeft geen betekenis buiten de context 
van de relatie Hoofdvak. De kop van het rapport bevat bovendien een dubbelzinnig- 
heid. Is het telefoonnummer voor de afdeling een waarde van VAKGROEP.Telefoon, 
of een waarde van PROFESSOR.Telefoon? Het team moet dat nader bespreken met 


de gebruikers. Het lijkt het meest waarschijnlijk dat dit een waarde is van VAK- 
GROEP.Telefoon. 
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FACULTEIT VAKGROEP PROFESSOR 
Professornaam 


Gebouw 
Kantoornummer 
Telefoon 


Telefoon 
AantalAfstuderenden 
Gebouw 

Kamer 


Decaannaam 
Telefoon 
Gebouw 


Studentnaam 
Telefoon 


Figuur 5-24 Datamodel met de entiteit STUDENT 


5.4.4 De toelatingsbrief voor studenten 

Je ziet de toelatingsbrief die de universiteit aan nieuwe studenten stuurt in Figuur 
5-25. De gegevensitems in deze brief die in het datamodel moeten komen, zijn vet 
weergegeven. Deze brief bevat naast gegevens over de student ook gegevens over het 
hoofdvak en de begeleider van de student. 


De heer Fred Plooistra 
Lantvoortweg 23 
2345 FG Bergendijke 


Geachte heer Plooistra, 


U bent voor het collegejaar 2011-2012 toegelaten tot de afstudeerfase in de vakgroep Accountancy van 
de universiteit van Leiderhoven. Het bureau van de vakgroep Accountancy is gevestigd in het gebouw B2, 
Kamer 210. 


Uw begeleider is professor Elizabeth de jagt. Haar telefoonnummer is 232-8740 en haar kantoor bevindt 
zich in het gebouw B2, Kamer 227. U wordt verzocht direct aan het begin van het nieuwe collegejaar 
contact met haar op te nemen. 


Gefeliciteerd en succes met uw afstudeeropdracht! 
Hoogachtend, 


Jan P. Smirks 
Faculteitsvoorzitter 


JPS 
Figuur 5-25 Toelatingsbrief 
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We kunnen deze brief gebruiken om een relatie ‘Begeleidt/Wordt begeleid door’ aan 
het datamodel toe te voegen. Maar welke entiteit moet de parent zijn in deze rela- 
tie? Een begeleider is een professor. Het is dan ook verleidelijk PROFESSOR tot de 
parent te maken. Een professor fungeert echter als een begeleider binnen het kader 
van een bepaalde vakgroep. Figuur 5-26 toont daarom BENOEMING als de parent 
van Begeleidt/Wordt begeleid door. Willen we de brief uit Figuur 5-25 produceren, 
dan kunnen we de gegevens over de professor ophalen door de gerelateerde entiteit 
BENOEMING aan te spreken en dan de parent PROFESSOR van deze entiteit op te 
halen. Dat is echter geen pasklare oplossing. Het is goed mogelijk te argumenteren 
dat PROFESSOR de parent van de relatie zou moeten zijn. 


FACULTEIT VAKGROEP PROFESSOR 


Faculteitnaam ‚ 


Gebouw 


Decaannaam dd Telefon OEE nn een pe ene 
Telefoon AantalAfstuderenden Kantoornummer 
Gebouw Gebouw Telefoon 


Kamer 


Kamer 


Î 
Î 
Hoofdvak, 
Î 
1 
1 


le) 
STUDENT A 


StudentNaam 
HuisadresStraat Sn 3 


HuisadresPlaats Begeleidt/Wordt 
HuisadresPostCodel| begeleid door 


Î 
Î 
I 
Titel | 
1 
Û 


Figuur 5-26 Datamodel met begeleiderrelaties 


Een student heeft volgens dit datamodel hoogstens één begeleider. Een student moet 
verder een begeleider hebben, maar geen enkele professor is verplicht studenten 
te begeleiden (via BENOEMING). Deze randvoorwaarden zijn niet te bepalen op 
basis van de getoonde rapporten. Ze moeten daarom gecontroleerd worden door 
met de gebruikers te spreken. De toelatingsbrief gebruikt de titel Geachte heer in de 
aanhef. We voegen daarom een nieuw attribuut met de naam Titel aan STUDENT 
toe. Merk op dat deze Titel verschilt van die in BENOEMING. Dat verschil moet in 
het datamodel gedocumenteerd worden, om verwarring te vermijden. De toelatings- 
brief maakt bovendien duidelijk dat we nieuwe attributen voor het thuisadres aan 
STUDENT moeten toevoegen. 

De toelatingsbrief onthult een probleem. De naam van de student is Fred Plooistra, 
maar we hebben maar één attribuut (Studentnaam) toegekend in STUDENT. Het 
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is moeilijk de voor- en achternaam op een betrouwbare manier uit een enkel at- 
tribuut te ontwarren. Het is dus een beter model als we twee attributen gebruiken: 
StudentVoornaam en StudentAchternaam. Merk ook op dat de naam van de begelei- 
der in deze brief Elizabeth de Jagt is. Alle namen van professoren werden tot dusver 
genoteerd in de indeling de Jagt, Elizabeth. We zullen Professornaam in PROFES- 
SOR in de beide attributen ProfessorVoornaam en ProfessorAchternaam moeten 
veranderen om beide vormen te kunnen gebruiken. Een soortgelijke wijziging is no- 
dig voor Decaannaam. Je ziet deze wijzigingen in Figuur 5-27. Dit is de uiteindelijke 
vorm van het datamodel. 


FACULTEIT VAKGROEP PROFESSOR 


Vakgroepnaam | 


|Zit voor/Voorgezeten doo 


ProfessorVoornaam 
r [ProfessorAchternaam 
fi 


AantalAfstuderenden 
Gebouw 
Kamer 


Gebouw 
Kantoornummer 
Telefoon 


Hoofdvak 


STUDENT 


Titel 
StudentVoornaam 


HuisadresStraat 
HuisadresPlaats 

HuisadresProvincie 
HuisadresPostCode|| 


Begeleidt/Wordt 
begeleid door 


Figuur 5-27 Het uiteindelijke datamodel 


Deze paragraaf zou je een idee moeten geven van de aard van een project voor het 
modelleren van gegevens. De formulieren en rapporten worden één voor één beke- 
ken, en het datamodel wordt telkens aangepast om de opgedane kennis uit elk nieuw 
rapport of formulier te integreren. Het is gebruikelijk en noodzakelijk het datamodel 
heel, heel veel keren te wijzigen tijdens het proces van het modelleren van gegevens. 


Samenvatting 


Een database die wordt ontwikkeld als onderdeel van een nieuw informatiesysteem 
wordt in twee fasen ontworpen. Eerst wordt er een datamodel opgesteld op basis van 
formulieren, rapporten, gegevensbronnen en andere eisen. Het datamodel wordt 
daarna omgezet in een databaseontwerp. Een datamodel is een blauwdruk voor een 
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databaseontwerp. Datamodellen kunnen, net als blauwdrukken voor gebouwen, zo 
nodig zonder veel moeite worden gewijzigd. Is de database eenmaal gemaakt, dan 
nemen dergelijke wijzigingen echter veel tijd in beslag en kosten ze veel geld. 

Het meest vooraanstaande datamodel dat tegenwoordig in gebruik is, is het enti- 
teit-relatiemodel, of kortweg E-R-model. Dit model is uitgevonden door Peter Chen 
en door anderen uitgebreid met subtypen. Een entiteit is een ding dat de gebruikers 
willen volgen. Een entiteitenklasse is een verzameling entiteiten van hetzelfde type. 
Een entiteitenklasse wordt beschreven door de structuur van de entiteiten in de klas- 
se. Een instantie van een entiteit is een enkele entiteit van een gegeven klasse. Enti- 
teiten hebben attributen die hun kenmerken beschrijven. Identifiers zijn attributen 
die instanties van entiteiten benoemen. Samengestelde identifiers bestaan uit twee 
of meer attributen. 

Het E-R-model omvat associaties tussen entiteiten die relaties worden genoemd. 
Relatieklassen zijn associaties tussen entiteitenklassen. Relatie-instanties zijn as- 
sociaties tussen instanties van entiteiten. Relaties mogen tegenwoordig geen at- 
tributen hebben. Er kunnen namen aan relaties worden gegeven, zodat ze zijn te 
identificeren. 

De graad van een relatie is het aantal soorten entiteiten dat aan de relatie deel- 
neemt. Binaire relaties hebben maar twee soorten entiteiten. Relaties met een graad 
groter dan twee worden in de praktijk ontleed in meer binaire relaties. 

Het verschil tussen een entiteit en een tabel is dat je een entiteitenrelatie kunt 
uitdrukken zonder externe sleutels op te geven. Het werken met entiteiten vermin- 
dert de complexiteit en maakt het makkelijker het datamodel te herzien tijdens het 
verloop van het werk. 

Relaties worden geclassificeerd overeenkomstig hun kardinaliteit. De maximum- 
kardinaliteit is het maximumaantal instanties van entiteiten dat aan een instantie 
van een relatie kan deelnemen. De minimumkardinaliteit is het minimale aantal en- 
titeiten dat aan een relatie moet deelnemen. 

Relaties hebben gewoonlijk een van drie maximumkardinaliteiten: r:1, r:N of 
N:M. De maximumkardinaliteit kan in zeldzame gevallen een specifiek aantal zijn, 
zoals 1:15. Relaties hebben gewoonlijk een van vier minimumkardinaliteiten: optio- 
neel-tot-optioneel (O-O), verplicht-tot-optioneel (M-O), optioneel-tot-verplicht (O-M) 
of verplicht-tot-verplicht (M-M). De minimumkardinaliteit kan in zeldzame gevallen 
een specifiek aantal zijn. 

Er zijn jammer genoeg veel varianten van het E-R-model in gebruik. De originele 
versie gaf relaties weer met ruiten. De Information Engineering-versie gebruikt een 
lijn met een kraaienpoot, de versie IDEFrX gebruikt andere en UML nog weer an- 
dere symbolen. We gebruiken in dit boek het kraaienpootmodel zoals dat in Figuur 
5-14 is samengevat. Je vindt een samenvatting van andere modellen en technieken 
in de bijlagen B, Cen D. 

Een ID-afhankelijke entiteit is een entiteit waarvan de identifier de identifier van 
een andere entiteit omvat. Dergelijke entiteiten gebruiken een identificerende rela- 
tie. De parent is altijd vereist in een dergelijke relatie, maar de child (de ID-afhanke- 
lijke entiteit) kan al dan niet vereist zijn, afhankelijk van de eisen van de applicatie. 
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Identificerende relaties worden in E-R-diagrammen weergegeven met doorgetrok- 
ken lijnen. 

Een zwakke entiteit is een entiteit die alleen kan bestaan als een andere entiteit 
ook bestaat. ID-afhankelijke entiteiten zijn altijd zwak. Er kunnen entiteiten voor- 
komen die zwak, maar niet-ID-afhankelijk zijn. Sommige mensen geloven dat der- 
gelijke entiteiten niet belangrijk zijn, terwijl andere het tegenovergestelde menen. 

Een subtype-entiteit is een speciaal geval van een andere entiteit, die het super- 
type van die entiteit wordt genoemd. Subtypen kunnen exclusief of inclusief zijn. 
Exclusieve subtypen hebben soms discriminators — dat zijn attributen die het sub- 
type van een supertype specificeren. De belangrijkste (en misschien wel enige) reden 
voor het maken van subtypen in een datamodel is het vermijden van niet-toepasse- 


lijke nullwaarden. 


Relaties tussen entiteiten die geen subtypen zijn, noemen we HEEFT-EEN-rela- 
ties. Relaties tussen subtypen noemen we IS-EEN-relaties. 

De elementen van een datamodel worden gemaakt door formulieren, rapporten 
en gegevensbronnen te analyseren. Het proces van het modelleren van gegevens is 
iteratief. Er worden formulieren en rapporten geanalyseerd, het datamodel wordt ge- 
maakt en daarna zo nodig aangepast en gewijzigd. De analyse van een formulier of 
een rapport kan het nodig maken dat je eerder werk moet overdoen. Zo is het leven 


nu eenmaal. 
Belangrijke termen 


associatierelatie 
attribuut 

binaire relatie 

child 

datamodel 
discriminator 
één-op-één (r:r)-relatie 
één-op-veel (r:N)-relatie 
entiteit 
entiteitenklasse 
entiteitinstantie 
entitity-relationship(E-R)-diagram 
exclusief subtype 
graad van relatie 
HEEFT-EEN-relatie 
ID-afhankelijke entiteit 
identificerende relatie 
identifier 
inclusief subtype 
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kardinaliteit 

kraaienpoot 

kraaienpootmodel 
maximumkardinaliteit 
minimumkardinaliteit 
niet-identificerende relatie 
optioneel-tot-optionele (O-O)-relatie 
optioneel-tot-verplichte (O-M)-relatie 
parent 

samengestelde identifier 

sterke entiteit 

subtype 

supertype 

ternaire relatie 

Unified Modeling Language (UML) 
veel-op-veel (N:M-)relatie 
verplicht-tot-optionele (M-O)-relatie 
verplicht-tot-verplichte (M-M)-relatie 
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zwakke entiteit relatieklasse 
relatie relatie-instantie 
Oefeningen 


1. _ Beschrijf de twee fasen voor het ontwerpen van databases die resulteren uit het 
ontwikkelen van nieuwe informatiesystemen. 

2. Leg in algemene termen uit hoe je een datamodel kunt gebruiken voor het ont- 
werpen van een database voor een kleine zaak die videofilms verhuurt. 

3. Leg uit in hoever een datamodel op een blauwdruk voor een gebouw lijkt. Wat is 
het voordeel van het uitvoeren van wijzigingen tijdens het stadium van het mo- 
delleren van gegevens? 

4. Wie is de auteur van het entiteit-relatiediagram? 

5. Definieer het begrip entiteit. Geef twee voorbeelden van entiteiten (andere dan 
in dit boek staan). 

Leg uit wat het verschil is tussen een entiteitenklasse en een entiteitinstantie. 

7. Definieer het begrip attribuut. Geef een voorbeeldattribuut voor de entiteit uit 
het antwoord op vraag 5. 

8. Definieer het begrip identifier. Geef een voorbeeldidentifier voor de entiteit uit 
het antwoord op vraag 5. 

9. Geef een voorbeeld van een samengestelde entiteit. 

to. Definieer het begrip relatie. Bedenk zelf een voorbeeld van een relatie. Geef 
deze relatie een naam. 

1. Leg uit wat het verschil is tussen een relatieklasse en een relatie-instantie. 

12. Wat is de relatiegraad? Bedenk zelf een voorbeeld van een derdegraads relatie. 

13. Wat is een binaire relatie? 

14. Leg uit wat het verschil is tussen een entiteit en een tabel. Waarom is dat verschil 
belangrijk? 

15. Wat wordt er bedoeld met kardinaliteit? 

16. Definieer de termen maximumkardinaliteit en minimumkardinaliteit. 

17. Bedenk zelf een voorbeeld van een r:1-, een t:N- en een N:M-relatie. Gebruik de 
traditionele ruitnotatie voor het maken van diagrammen voor deze voorbeelden. 

18. Geef een voorbeeld waarvoor de maximumkardinaliteit een precies getal moet 
zijn. 

ig. Bedenk zelf een voorbeeld van een M-M-, een M-O-, een O-M- en een O-O-rela- 
tie. Gebruik de notatie met rondjes en kruisstrepen naast de ruit voor het weer- 
geven van de relaties. 

20. Leg in algemene termen uit hoe het traditionele E-R-model, de Information En- 
gineering-versie (het kraaienpootmodel), de IDEFrX-versie en de UML-versie 
van elkaar verschillen. Welke versie wordt voornamelijk gebruikt in dit boek? 

21. Leg uit hoe de notaties die je in Figuur 5-7 ziet van elkaar verschillen. 

22. Wat is een sterke entiteit? 


23. Wat is een ID-afhankelijke entiteit? Bedenk zelf een voorbeeld van een ID-af- 
hankelijke entiteit. 
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24. 


25. 


26. 


27. 


28. 


29. 


30. 


31. 


32. 
33- 


34. 


35: 


44. 


45: 
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Leg uit hoe je de minimumkardinaliteit bepaalt aan beide kanten van een ID- 
afhankelijke relatie. 
Welke regels gelden er tijdens het maken van een instantie van een [D-afhanke- 


lijke entiteit? Welke regels gelden er tijdens het verwijderen van de parent van 
een ID-afhankelijke entiteit? 


Wat is een identificerende relatie? Hoe wordt deze gebruikt? 


Leg uit waarom de relatie tussen PRODUCT en VERSIE een identificerende re- 
latie is. 


Wat is een zwakke entiteit? Wat is de relatie tussen zwakke entiteiten en ID-af- 
hankelijke entiteiten? 


Wat onderscheidt een zwakke entiteit van een sterke entiteit die een vereiste re- 
latie heeft naar een andere entiteit? 


Definieer subtype en supertype. Bedenk zelf een voorbeeld van een subtype/ 
supertype-relatie. 


Leg uit wat het verschil is tussen exclusieve subtypen en inclusieve subtypen. 
Geef een voorbeeld van elk daarvan. 


Wat is een discriminator? 
Leg uit wat het verschil is tussen IS-EEN- en HEEFT-EEN-relaties. 


Wat is de belangrijkste reden voor het gebruik van subtypen in een datamodel? 
Beschrijf de relatie tussen de structuur van formulieren en rapporten en de 
structuur van het datamodel. 


Noem twee manieren waarop formulieren en rapporten worden gebruikt voor 
het modelleren van gegevens. 


Beschrijf twee tests waarmee te bepalen is of een entiteit sterk is. 


Waarom geeft het formulier uit Figuur 5-15 niet aan dat de onderliggende relatie 
EN is? Welke extra informatie is er nodig om dat te kunnen bepalen? 


. Leg uit waarom er gewoonlijk twee formulieren of rapporten nodig zijn om de 


minimumkardinaliteit af te leiden. 


„ Hoe kun je beoordelen wat de minimumkardinaliteit is voor de entiteiten in het 


formulier uit Figuur 5-15? 


„ Noem drie patronen die gebruikmaken van ID-afhankelijke relaties. 
. Leg uit waarin de associatierelaties verschillen van het N:M sterke entiteitenpa- 


troon. Welk kenmerk van het rapport uit Figuur 5-15 geeft aan dat er een associ- 
atierelatie nodig is? 


. Leg uit waarom er twee entiteiten nodig zijn voor het modelleren van meerwaar- 


dige attributen. 


Vat samen wat de beide kanten zijn in het argument over het belang van zwak- 
ke, maar niet-ID-afhankelijke entiteiten. 


Bedenk zelf een voorbeeld van een 1:1, een 1;N en een N:M recursieve relatie. 


„ Leg uit waarom het proces van het modelleren van gegevens herhaald moet zijn. 


Gebruik het voorbeeld van de universiteit van Leiderhoven. 


GEGEVENS MODELLEREN MET HET ENTITEIT-RELATIEMODEL 


Projectvragen 


47. Deze vraag is voor gebruikers van MS Visio. Zet de datamodellen uit Figuur 
5-18, Figuur 5-20 en Figuur 5-27 om in de indeling van MS Visio. Gebruik de 
pijlnotatie van MS Visio. 

48. Deze vraag is voor gebruikers van MS Visio. Zet de datamodellen uit Figuur 
5-18, Figuur 5-20 en Figuur 5-27 om in de indeling van MS Visio. Gebruik de MS 
Visio-versie van het kraaienpootmodel. 


Beantwoord de volgende vragen met behulp van de kraaienpootnotatie: 
49. Bekijk het aanmeldformulier in Figuur 5-28. Gebruik de structuur van dit for- 
mulier voor de volgende taken: 

a. Maak een model met een enkele entiteit. Geef de identifiers en attributen 
op. 

b. Maak een model met twee entiteiten: een voor de klant en een voor het 
abonnement. Geef identifiers, attributen, relatienamen, relatietypen en kar- 
dinaliteiten op. 

c. Onder welke omstandigheden zou je de voorkeur geven aan het model in a 
boven dat in b? 

d. Onder welke omstandigheden zou je de voorkeur geven aan het model in b 


boven dat in a? 


JA! Ik 


word 
Ká A AAabonnee 


[1 jaar (6 nummers) voor maar € 18 
(20% korting op losse-verkoopprijs) 
O2 jaar (12 nummers) voor maar € 34 
(U bespaart 24%!) 
Naam 
Adres 


Woonplaats —__—__________ Land Postcode 
DO Betaling is ingesloten 0 Stuur mij een rekening 
Ik begin mijn abonnement met ingang van: 

0 dit nummer DO het volgende nummer 


Figuur 5-28 Aanmeldformulier 


5o. Bekijk de bekeuring in Figuur 5-29. De afgeronde hoeken van dit formulier 
geven grafische aanwijzingen over de grenzen van de hier gerepresenteerde 
entiteiten. 
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a. Maak een datamodel met vijf entiteiten. Gebruik de gegevensitems in het 
formulier voor het opgeven van identifiers en attributen van deze entiteiten. 

b. Specificeer de relaties tussen de entiteiten. Geef elke relatie een naam en 
geef het type en de kardinaliteiten ervan op. Geef aan welke kardinaliteiten 
zijn af te leiden uit de gegevens in het formulier en welke met de gebrui- 
kers van het systeem moeten worden besproken. 


WAARSCHUWING GEMEENTEPOLITIE DE VUURSCHE 


Naam Kroenke David M. 
Achternaam Voornaam 
adres Weg van de vrijheid 15 
paas Utrecht sure Wa Posteooe3551 BE 
Rupewjsnummer STATE Geb. daten |LengtefGeaicht Meur 
0000 wa || 27/2/46 85 ogen bl 
Kentekennr STATE | Keu Merk Typo 
Arsbooo [a |ereenls0 | san | 530 


Datum overvedng Wijk 
Deal meme, 7 Jer 2007 rw, 935 
Locate 

17 moa Opening Hilversum pas SR410 


Aan het schrijven tijdens het rijden 


Det in een waarschumng. geen verders acte 
U dent het voertug derect te laten repareren. 
Voortgezet gebruk op de cpenbars weg is verboden 


onmiddelijk. Lever deze kaart getekerd 
rde poltseburoau 


Figuur 5-29 Bekeuring 


si. Bekijk de lijst met e-mailberichten in Figuur 5-30. Gebruik de structuur en de 
voorbeeldgegevens in deze lijst en doe het volgende: 

a. Maak een datamodel met een enkele entiteit voor deze lijst. Geef de identi- 
fier en alle attributen op. 

b. Wijzig je antwoord op a en neem de entiteiten AFZENDER en ONDER- 
WERP op. Geef identifiers en attributen van entiteiten en kardinaliteiten 
van relaties op. Licht toe welke kardinaliteiten uit Figuur 5-30 zijn af te lei- 
den en welke met de gebruikers zullen moeten worden besproken. 

c. Er komen twee verschillende stijlen e-mailadressen voor in de kolom From 
in Figuur 5-30. De ene stijl geeft het echte e-mailadres weer. De tweede stijl 
geeft de naam van een regel in het e-mail-adresboek van de gebruiker weer 
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(zoals Tom Cooper). Maak twee categorieën van AFZENDER voor deze twee 
stijlen. Geef identifies en attributen op. 


in GUbIet Date } iede 


in WDA2259@sailmail.com Big Wind 5/13/2002 3 KB 
IE WDA2259@sailmail.com Update 5/12/2002 4 KB 
nf WDA2259@sailmail.corn Re: Saturday Am 5/11/2002 4 KB 
5 WDA2259@sailmail.com Re: Weather window! 5/10/2002 4 KB 
| WDA2259@sailmail.com Re: Howdy! 5/10/2002 3 KB 
fas WDA2259@sailmail.com Stull here 5/9/2002 3 KB 
fer WDA2259@sailmail.com Re: Turle Bay 5/8/2002 4 KB 
Ta WDA2259@sailmail.com Turle Bay 5/8/2002 4 KB 
in WDA2259@sailmail.com Re: Hi 5/6/2002 3 KB 
Ts WDA2259@sailmail.com Sunday, Santa Maria 5/5/2002 3 KB 
ra Ki6yu@aol.com Cabo, Thurs. Noon 5/2/2002 2 KB 
je WDA2259@sailmail.com turbo 5/1/2002 3 KB 
rf WDA2259@sailmail.com on our way 4/28/2002 3 KB 
Fn Tom Cooper RE: Hola! 4/26/2002 3 KB 
pen Tom Cooper RE: Hola! 4/24/2002 2 KB 
kn Tom Cooper RE: Hola! 4/23/2002 3 KB 


Figuur 5-30 Lijst met e-mailberichten 


Bekijk de lijst met aandelenkoersen in Figuur 5-31. Gebruik de structuur en de 
voorbeeldgegevens in deze lijst en doe het volgende: 


a. 


b. 


Maak een datamodel met een enkele entiteit voor deze lijst. Geef de identi- 
fier en alle attributen op. 

Wijzig je antwoord op a en neem de entiteiten BEDRIJF en INDEX op. Geef 
identifiers en attributen van entiteiten en kardinaliteiten van relaties op. 
Licht toe welke kardinaliteiten uit Figuur 5-31 zijn af te leiden en welke met 
de gebruikers moeten worden besproken. 

De lijst in Figuur 5-31 toont de koersen op een bepaalde tijd van een bepaal- 
de dag. Stel dat deze lijst zou worden veranderd om de dagelijkse afsluit- 
prijzen te laten zien voor elk van de aandelen en dat er een nieuwe kolom 
QuoteDate zou worden toegevoegd. Pas je model uit b overeenkomstig aan. 
Wijzig je model uit c om een portfolio bij te houden. Neem aan dat de port- 
folio de volgende gegevens omvat: naam van eigenaar, e-mailadres en een 
lijst met aandelen in de portfolio. De lijst omvat de identiteit van de aande- 
len en de aandeelnummers. Geef alle extra entiteiten op, evenals hun iden- 
tifiers en attributen en het type en de kardinaliteiten van alle relaties. 
Wijzig je antwoord op vraag d om de verkoop en aankoop van aandelen bij 
te houden voor een portfolio. Geef entiteiten op, evenals hun identifiers en 
attributen, en geef het type en de kardinaliteiten van alle relaties op. 
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Symbol Name Last Change %Chgy 
SCOMPX Nasdag Cornbined Composite Index 1,400.74 v -487 -0.35% 
SINDU Dow Jones Industrial Average Index 925510 1 -1980 -021% 
SINX S&P 500 INDEX 97114 YY -584 -060% 
ALTR Altera Corporation 13.45 1 -0.450 -324% 
AMZN Amazon.com, Inc. 1552 +068) +4 55% 
CS5CO Cisco Systems, Inc. 1339 + -0.280 -205% 
DELL Dell Computer Corporation 2458 v -0170 -069% 
ENGCX Enterprise Growth C 1460 1 -0.210 -1.42% 
INTC Intel Corporation 1812 1 -0.380 -205% 
JNJ Johnson & Johnson 5329 v -0290 -054% 
KO Coca-Cola Campany 5670 1 -0.580 -1.01% 
MSFT Microsoft Corporation 3.96 + +1.040 +1 47% 
NKE NIKE, Inc. 57342 +0580 +1 02% 


Figuur 5-31 Aandelenkoersen 


53. Figuur 5-32 toont de specificaties van luchtcompressors. Merk op dat er twee 
categorieën producten zijn voor verschillende prestatiekenmerken (Air Perfor- 
mance): de A-modellen leveren een luchtdruk van 125 pond per vierkante inch 
en de B-modellen een luchtdruk van 150 pond per vierkante inch. Gebruik de 
structuur en de voorbeeldgegevens in deze lijst en doe het volgende: 

a. Maak een verzameling exclusieve subtypen voor het representeren van deze 
compressors. Het supertype zal attributen hebben voor alle compressors, 
de subtypen zullen attributen hebben voor producten met de twee verschil- 
lende prestatiekenmerken. Neem aan dat er andere producten kunnen zijn 
met andere prestatiekenmerken. Geef de entiteiten, identifiers, attributen, 
relaties, het supertype en mogelijke determinanten op. 

Figuur 5-33 laat een ander model zien voor de compressorgegevens. Noem 

de entiteiten, hun type, de relaties en hun kardinaliteiten. Hoe goed komt 

dit model volgens jou overeen met de gegevens in Figuur 5-32? 

c._ Vergelijk je antwoord uit vraag a met het model in Figuur 5-33. Wat zijn de 
essentiële verschillen tussen de beide modellen? Welk model is volgens jou 
beter? 

d. Stel dat het jouw taak is de verschillen tussen de beide modellen uit te leg- 
gen aan een goed gemotiveerde, intelligente eindgebruiker. Hoe zou je dat 
doen? 

54. Figuur 5-34 toont een lijst van tijden voor filmvoorstellingen in bioscopen in 
Seattle. Gebruik deze gegevens als voorbeeld en doe het volgende: 

a. Maak een model voor het representeren van dit rapport, met de entiteiten 
FILM, BIOSCOOP en VOORSTELLING. Neem aan dat de bioscopen naast 
deze film ook nog andere films kunnen laten zien. Dit rapport is voor een 
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Single Stage 


Set 95 to PSI also available, substitute "E“ for in model number. i.e, K15A-30 make K15E-30 


Dimensions 


Air Performance 


Ĳ 
Pump 
RPM 

(seo | 


Approx 
Ship 
Weight 


E@ 150 


Model 


z 


ee 


DEL'D 
Aur 


12 F12A-17 


L 
3/4 F34A-17 L 17_|[soeo | a50 
3/4 F34A-20 zo || 1oeo | 5: aso 


3.1 
tE] K14-20 BEE seo | ez [so | 
1 12 kK15a30 | zo \Lszo (os 6.2 
K15A-B0 IL so | 870 [28 
K2A-30 | 20 |[ 1140 121 
K2A-50 eo |f 1140 | 124 
GC2A-30 En aso | 124 


IN 


[: 
É 


| 
r 


» 


J 


elfellefe |=) È 7 


PRESTATIE TYPE 


LuchtdrukPrestaties 


HP 
TankOmvang 
GeschatLeegGewicht 

Lengte { 
Breedte 
Hoogte 


LuchtdrukPrestaties 
PompRPM 
Luchtverplaatsing CFM 


De ee el 


Figuur 5-33 Alternatief model voor compressorgegevens 


bepaalde dag. Jouw datamodel moet echter ook rekening houden met voor- 
stellingen op andere dagen. Geef de identifiers en de attributen van de en- 
titeiten op. Noem de relaties, het type van de relaties en de kardinaliteiten 
van alle relaties. Leg uit welke kardinaliteiten uit Figuur 5-34 zijn af te lei- 
den en welke met de gebruikers moeten worden besproken. Neem aan dat 
Afstand een attribuut is van BIOSCOOP. 

b. Dit rapport is voorbereid voor een gebruiker die zich in de binnenstad van 
Seattle bevindt. Neem aan dat hetzelfde rapport voor deze bioscopen moet 
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worden geproduceerd, maar nu voor een gebruiker die zich in een buiten- 
wijk van Seattle bevindt, zoals Bellevue, Renton, Redmond of Tacoma. Af- 
stand kan in dat geval geen attribuut zijn van BIOSCOOP. Verander het 
antwoord op vraag a voor deze situatie. Geef de identifiers en de attributen 
van de entiteiten op. Noem de relaties, het type en de kardinaliteiten van 
alle relaties. 
Stel nu dat je dit datamodel heel Amerika wilt laten omvatten. Verander het 
antwoord op vraag b zodat het model bruikbaar is voor andere stedelijke ge- 
bieden. Verander het antwoord op vraag a voor deze situatie. Geef de identi- 
fiers en de attributen van de entiteiten op. Noem de relaties, het type en de 
kardinaliteiten van alle relaties. 
Verander het antwoord op vraag cen neem de hoofdrolspelers op. Neem 
aan dat de rol van een hoofdrolspeler niet gemodelleerd moet worden. Geef 
de identifiers en de attributen van de nieuwe entiteiten op. Noem de nieu- 
we relaties, het type en de kardinaliteiten van alle relaties. 
Verander het antwoord op vraag c en neem de hoofdrolspelers op. Neem 
aan dat de rol van een hoofdrolspeler is opgegeven. Geef de identifiers en de 
attributen van de nieuwe entiteiten op. Noem de nieuwe relaties, het type 


en de kardinaliteiten van alle relaties. 


Men in Black II 


Even Tommy Lee Jones at his funniest can't save Will Smith or this 
goofy alien flick from sequel-itis. 


Local Theaters and Showtimes 


40 miles from the center of Seattle, WA Change Area 
Tue, Jul 9 Wed Thu Fri Sat 


Displaying 1 - 32 results, sorted by distance, 


AMC P acific Place 11 (0.5 miles) 
600 Pine St, Seattle (206) 652-2404 
Showtimes: 11:00 am, 12:00 pm, 12:45 pm, 1:30 pm, 2:30 pm, 3:15 pm, 4:00 


pm, 5:00 pm, 5:45 pm, 6:30 pm, 7:30 pm, 8:30 pm, 9:00 pm, 10:00 pm, 10:45 
pm 


(3.9 miles) 
jas NE 45th, Seattle (206) 633-5545 
Showtimes: 11:20 am, 1:30 pm, 3:40 pm, 5:50 pm, 8:00 pm, 10:10 pm 


Regal Bellevue Galleria 11 (6.2 miles) 

500 106th Ave NE, Bellevue (425) 451-7161 

Showtimes: 11:00 am, 11:30 am, 1:00 pm, 1:30 pm, 3:00 pm, 3:30 pm, 5:05 
pm, 5:35 pm, 7:10 pm, 7:40 pm, 9:20 prn, 9:50 pm 


LCE Oak Tree Cinema (6.6 miles) 
10006 Aurora Ave N., Seattle (206) 527-1748 
Showtimes: 11:45 am, 2:15 pm, 4:45 pm, 7:15 pm, 9:45 pm 


LCE Factoria Cinemas 8 (7.8 miles) 

3505 Factoria Blvd SE, Bellevue (425) 641-9206 

Showtimes: 12:00 pm, 1:00 pm, 2:15 pm, 3:15 pm, 4:30 pm, 5:45 pm, 7:30 
pm, 8:15 pm, 9:45 pm, 10:30 pm 


Kirkland Parkplace Cinema (8 miles) 
404 Parkplace Ctr, Kirkland (425) 827-9000 
Showtimes: 12:15 pm, 2:30 pm, 4:45 pm, 7:20 pm, 9:35 pm 


Figuur 5-34 Tijden van filmvoorstellingen 
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55. Bekijk de drie rapporten in Figuur 5-35. De gegevens zijn voorbeeldgegevens die 
in dergelijke rapporten kunnen voorkomen. 

a. Maak een lijst met alle potentiële entiteiten in deze rapporten. 

b. Bekijk je lijst en bepaal of er entiteiten voorkomen die synoniemen zijn. 
Consolideer de lijst als dat het geval is. 

c. Maak een kraaienpootmodel dat de relaties tussen je entiteiten aangeeft. 
Geef elke relatie een naam en geef kardinaliteiten op. Geef aan welke kardi- 
naliteiten je kunt rechtvaardigen op basis van de rapporten en welke je met 
de gebruikers moet bespreken. 


%e RAPPORTNR #6272 
Datum: 30/06/2001 


Van: Kellogg's Corporation 
Rapporttitel: Productoverzicht naar ingrediënten 
Maïs Corn Flakes 


® Krispix 
KRISPI ES Nutrigrain (maïs) 
Maïssiroop Rice Krispies 


Frosted Flakes 


Voedingsinformatie Sugar Pops 

Aantal porties per pakt 13 Mout Rice Krispies 

Bevat per portie met(ont- Sugar Smacks 
ban es Tarwe Sugar Smacks 
Kootnaratant fas EE Nutrigrain (tarwe) 
Vet 
Cholesterol Omg me 
Natnum 290mg 350mg 
Kalium 35mg 240mg 
PERCENTAGE OF U.S. RECOMMENDED (a) 


DAILY ALLOWANCES (U.S. RDA) 


PROTEIN 2 10 
VIAMNA 2 35 LEVERANCIERSOVERZICHT 
THIAMIN 40 Datum: 30/06/2001 | 
RIBOFLAVIN 35 45 | 
CALCIUM - 15 
VND de 40 Ingrediënt | Leverancier 
VITAMIN Bz 35 35 Î 
FOUGACID 35 35 E 7 | 
PHOSPHORU 4 1 
HAGNESIUM ô 6 Mais Willems ; 
COPPER 2 4 Perk 

“WHOLE MILK SUPPLIES AN ADDITIONAL 30 Pollens 

CALORIES, 4 g FAT, AND 15mg CHOLESTEROL. 

“CONTAINS LESS THAN 2% OF THE U.S. RDA OF Mak 

THIS NATRIENT. 
Ingrediënten: rijst, suiker, zout, Adams 
VEEAMINSLAND Ì IRON: VITAMIN C Kroon 
ASCORHATE AND ASCORBIG ACID) Smid 
NIACINAMIDE, | A 
NIDOXINEEYDROCHLORIDE). VITAMIN A Willems 


ALTE VIT, anr Bz (RIBOFLAVIN), 
AMIN B, LAMIN 
HYDROCHL RIDE), 
FOLIC ACID, AND VITAMIN D. 
TO KEEP THIS CEREAL FRESH, BHT — 
HAS BEEN ADDED TO THE 
PACKAGING. (b) 


Pollens 


Figuur 5-35 Cornflakes-productrapporten 


179 


DEEL2 | DATABASES ONTWERPEN 


56. Bekijk de cd-hoes in Figuur 5-36. 


a. 


b. 


) Cool (4'37) 
Ongineie Broadwayproductie door Robert E. Griffith en (Riff, Chorus) 
Harold S. Pance in samenwerking met Roger L. Stevens. One Hand, One Heart [5'38) 
Arrangementenn door Leonard Bemstein met Sid Ramin en Irwin Kosta) (Tony, Maria) 
Hoogtepunten ult de integrale opname B] a oembe) 1949) 
% 5 | Feel Pretty [3'22] 
Marla Sor ie tete rate Afk KIRI TE KANAWA (Maria, Chorus) 
TD JOSE CARRERAS did [2'34) 
AE NE nd ore TATIANA TROYANOS sj 
Ef Gee Officer Krupke [4'18) 
ESE KURT OLLMAN UN ano Dieze A:rae ‘Bat dchm, Chorus) 
en MARILYN HORNE in“Somewhere” zl A Boy Like That [2'05) 
(Anita, Maria) 
Louise Edeiken _ Diesel... … Marty Nelson | [3] boog et eh [3'30) 


West Side Story 5 
4 et Song [3'13) 
Gebaseerd op een idee van Jerome Robbins nn) (Rift, Action, Baby John, A-rab, Chorus) 
El Something's Coming [2'33) 
Boek: ARTHUR LAURENTS (Tony) 


En) (Mana, Tony) 
Regie en choreografie: JEROME ROBBINS EE ae caro id 


Geef identifiers en attributen op voor de entiteiten CD, ARTIEST, ROL en 
NUMMER. 
Maak een kraaienpootmodel dat de relaties tussen deze drie entiteiten 
toont. Geef elke relatie een naam en geef de kardinaliteiten op. Geef aan 
welke kardinaliteiten je kunt rechtvaardigen op basis van de cd-hoes en wel- 
ke je met de gebruikers moet doornemen. 
Denk eens na over een cd die geen musical betreft, zodat ROL niet nodig is. 
Er is nu echter een entiteit SONGWRITER nodig. Maak een kraaienpoot- 
model voor CD, ARTIEST, NUMMER en SONGWRITER. Neem aan dat 
een ARTIEST een persoon of een groep kan zijn. Neem aan dat sommige 
artiesten alleen en als lid van een groep opnamen maken. 
Combineer de modellen die je hebt ontwikkeld in je antwoorden op vraag b 
en c. Maak zo nodig nieuwe entiteiten maar houd je model zo eenvoudig 
mogelijk. Geef identifiers en attributen van nieuwe entiteiten op, geef nieu- 
we relaties een naam en geef hun kardinaliteiten aan. 


Muziek: LEONARD BERNSTEIN foyp sera (2'56) 


Liedteksten: STEPHEN SONDHEIM Tonlaht sen 


„Stella Zambalis Baby Joho... Stephen Bogardus Taunting Scene 121) 

„Angelina Reaux —_ A-rab.…...…….…… Peter Thom | ÉÙ orchestra) 

David Livingston __Snowboy...… Todd Lester 5) Finale [2'40) 
Bemarda. „Richard Harrell (Maria, Tony) 


Figuur 5-36 Cd-hoes 


57. Het datamodel uit Figuur 5-27 gebruikt het attribuut Kamer in FACULTEIT en 
VAKGROEP, maar gebruikt Kantoornummer in PROFESSOR. Deze attributen 
bevatten hetzelfde soort gegevens, hoewel ze verschillende namen hebben. Be- 
kijk Figuur 5-21 en leg uit hoe deze situatie is ontstaan. Denk je dat het maar 
zelden voorkomt dat er verschillende namen zijn voor dezelfde soorten attribu- 
ten? Denk je dat dit een probleem is? Waarom, of waarom niet? 
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GEGEVENS MODELLEREN MET HET ENTITEIT-RELATIEMODEL 


Marcia’s Chemische Reiniging 


Stel dat je door Marcia’'s Chemische Reiniging bent ingehuurd om een databaseap- 
plicatie te maken voor het bijhouden van klanten, orders en items. Marcia wil ook 
een Frequent Cleaner’s Club beginnen, waarmee ze een korting van 50% biedt op 
elke tiende order van een klant. 

A. Gebruik je kennis om een datamodel te maken voor Marcia's bedrijf. Geef elke 
entiteit een naam, geef aan wat het type ervan is en geef alle attributen en iden- 
tifiers aan. Geef elke relatie een naam, beschrijf het type ervan en geef de mini- 
mum- en maximumkardinaliteiten op. 

B. Noem alle dingen uit A waarvan je denkt dat je ze met Marcia en/of haar werk- 
nemers moet bespreken. 


Importbedrijf Morgan 


Stel dat je door Importbedrijf Morgan bent aangenomen om een databaseapplicatie 
te maken voor het bijhouden van winkels, aankopen, verscheepte ladingen en expor- 
teurs. Soms worden er meer dingen tegelijk gekocht bij een enkel bezoek aan een 
winkel. Je mag echter niet aannemen dat al deze dingen in dezelfde lading worden 
verscheept. Je wilt elk item in een lading bijhouden en een verzekerde waarde aan 
elk item toekennen. 

A. Gebruik je kennis om een datamodel te maken voor Importbedrijf Morgan. 
Geef elke entiteit een naam, geef aan wat het type ervan is en geef alle attributen 
en identifiers aan. Geef elke relatie een naam, beschrijf het type ervan en geef 
de minimum- en maximumkardinaliteiten op. 

B. Noem alle dingen uit A waarvan je denkt dat je ze met Phillip Morgan en/of zijn 
werknemers moet bespreken. 
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Hoofdstuk 6 
Datamodellen omzetten in 
databaseontwerpen 


Dit hoofdstuk legt uit hoe je entiteit-relatiedatamodellen omzet in relationele data- 
baseontwerpen. Deze omzetting bestaat uit drie belangrijke stappen: (1) vervang 
entiteiten en attributen door tabellen en kolommen, (2) representeer relaties en 
maximumkardinaliteiten door externe sleutels op te nemen en (3) representeer de 
minimumkardinaliteiten door acties te definiëren die beperkingen opleggen aan de 
activiteiten die worden uitgevoerd op de waarden van primaire en externe sleutels. 
Stap 1 en stap 2 zijn relatief makkelijk te begrijpen en uit te voeren. Stap 3 kan mak- 
kelijk of moeilijk zijn, afhankelijk van het soort minimumkardinaliteit. 


DEEL 2 | OATABASES ONTWERPEN 


6,1 Maak een tabel voor elke entiteit 


Zoals je in Figuur 6-1 ziet, beginnen we het ontwerp van de database door voor elke 
entiteit een tabel te maken. In de meeste gevallen geef je de tabel dezelfde naam als 
de entiteit. Elk attribuut van de entiteit wordt een kolom van de tabel. De identifier 
van de entiteit wordt de primaire sleutel van de tabel. 


Maak een tabel voor elke entiteit. 
Geef de primaire sleutel op, overweeg indien nodig surrogaatsleutels. 
* Geef kandidaatsleutels op. 
Geef eigenschappen op voor elke kolom. 
* _nullstatus 
* datatype 
*_defaultwaarde (als die er zijn) 
* geef data constraints op (wanneer van toepassing) 
* Controleer de normalisatie. 
2. Maak relaties door externe sleutels op te nemen. 
e sterke relaties (1:1, t:N, N:M) 
*_1D-afhankelijke relaties (associatie, meerwaardige) 
+ gemengde relaties 
e relaties tussen super- en subtypen 
* __recursieve relaties (1:1, 1:N, N:M) 
3. Geef de logica op voor het handhaven van de minimumkardinaliteiten. 
e M-O 
* OM 
e_M-M 


Figuur 6-1 De stappen voor het omzetten van een datamodel in een databaseontwerp 


Het voorbeeld in Figuur 6-2 laat zien hoe de tabel WERKNEMER wordt gemaakt op 
basis van de entiteit WERKNEMER. We geven het verschil tussen entiteiten en tabel- 
len in dit boek aan door entiteiten weer te geven in rechthoeken met een schaduw, en 
tabellen in rechthoeken zonder schaduw. Deze notatie helpt ons de bespreking dui- 
delijker te maken. Wees je er echter wel van bewust dat dit geen standaardnotatie is. 

De rechthoek met een schaduw in Figuur 6-2(a) representeert een logische struc- 
tuur die niet fysiek bestaat — het is een blauwdruk. De rechthoek zonder schaduw in 


Figuur 6-2(b) representeert een tabel en komt overeen met de notatie zoals we die in 
de vorige hoofdstukken gebruikten: 


WERKNEMER (Werknemernummer, Werknemernaam, Telefoon, E-mail, 
DatumAangenomen, DatumBeoordeling, WnCode) 


Merk ook het sleutelsymbool op naast Werknemernummer. Dit symbool documen: 
teert het feit dat Werknemernummer de primaire sleutel van de tabel is, zoals de on- 
derstreping dat doet in de andere notatie. 
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WERKNEMER WERKNEMER 


Werknemernummer |, aN Werknemernummer 


Werknemernaam Werknemernaam 
Telefoon 

E-mail 
DatumAangenomen 
DatumBeoordeling 
WnCode 


DatumBeoordeling 
WnCode 


(a) De entiteit WERKNEMER (b) De tabel WERKNEMER 


Figuur 6-2 Een entiteit omzetten in een tabel 


6.1.1 De primaire sleutel kiezen 

De keuze van de primaire sleutel is belangrijk. Het DBMS gebruikt de primaire 
sleutel om het zoeken in en sorteren van tabelrijen te vereenvoudigen. Sommige 
DBMS-producten gebruiken de primaire sleutel ook voor het organiseren van de op- 
slagruimte voor de tabel. DBMS-producten maken vrijwel altijd indexen en andere 
gegevensstructuren op basis van de waarden van de primaire sleutel. 

De ideale primaire sleutel is kort, numeriek en onveranderlijk. Werknemernum- 
mer uit Figuur 6-2 voldoet aan al die voorwaarden en is dus acceptabel. Pas op voor 
primaire sleutels zoals Werknemernaam, E-mail, (Netnummer, Abonneenummer), 
(Straat, Plaats, Provincie, Postcode) en andere lange tekstkolommen. Overweeg in 
dergelijke gevallen (waarbij de identifier niet kort, numeriek en onveranderlijk is) 
een andere kandidaatsleutel te gebruiken als primaire sleutel. Als er geen andere 
kandidaatsleutels zijn, overweeg dan een surrogaatsleutel te gebruiken. 

Een surrogaatsleutel (surrogate key) is een door het DBMS geleverde identifier 
voor elke rij van een tabel. De waarden van een surrogaatsleutel zijn uniek binnen 
de tabel en ze veranderen nooit. Ze worden toegekend als de rij wordt gemaakt en ze 
worden vernietigd als de rij wordt verwijderd. Waarden van surrogaatsleutels zijn de 
best mogelijke primaire sleutels, want ze zijn ontworpen om kort, numeriek en on- 
veranderlijk te zijn. Sommige organisaties gaan vanwege deze voordelen zo ver dat 
ze eisen dat er een surrogaat wordt gebruikt voor de primaire sleutel van elke tabel. 


Opmerking 

Sommige databaseontwerpers zijn van mening dat je consequent moet handelen en dat alle tabellen 
in een database daarom een surrogaatsleutel moeten krijgen zodra er ook maar een tabel is die 

een surrogaatsleutel heeft. Andere mensen denken dat een dergelijk beleid te onbuigzaam is — er 

zijn tenslotte goede gegevenssleutels, zoals ProductiD. Is er een dergelijke sleutel, dan moet je deze 
gebruiken in plaats van een surrogaatsleutel. Jouw organisatie zal hiervoor misschien standaarden 
hebben waaraan je je moet houden. 

Je moet weten dat DBMS-producten verschillen in hun ondersteuning voor surrogaatsleutels. Microsoft 
Access levert ze rechtstreeks. Wij gebruiken altijd surrogaatsleutels, tenzij er een goede reden is dat 
niet te doen. Zoals je in het laatste deel van dit hoofdstuk zult zien, bieden ze niet alleen de hier 


beschreven voordelen. Het feit dat ze onveranderlijk zijn, vereenvoudigt ook het handhaven van de 
minimumkardinaliteit. 
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Surrogaatsleutels hebben ook nadelen. Om te beginnen hebben ze geen betekenis 
voor de menselijke gebruiker. Als je gegevens opvraagt uit een tabel WERKNEMER, 
en Afdelingsnaam is daarin een externe sleutel (van AFDELING), dan krijg je een 
betekenisvolle naam als Boekhouding of Secretariaat. Maar als AFDELING een sur- 
rogaatsleutel heeft, bijvoorbeeld AfdelingsID, dan zal dat ook de externe sleutel in 
WERKNEMER zijn en krijg je informatie als 1233559, wat niet veel zegt. Je moet dan 
een volgende query op AFDELING uitvoeren om de naam van de afdeling te krijgen. 

Een ander nadeel treedt op wanneer een bedrijf over verschillende databases 
beschikt met surrogaatsleutels met identieke waarden, en het bedrijf de databases 
wenst samen te voegen. Er is dan geen garantie dat de surrogaatsleutels uniek zijn 
in de samengevoegde database, met alle gevolgen van dien. 


6.1.2 Kandidaatsleutels opgeven 


De volgende stap in het maken van een tabel is het opgeven van kandidaatsleutels. 
Uit hoofdstuk 3 weet je dat kandidaatsleutels mogelijke identifiers zijn voor unieke 
rijen in een tabel. Sommige producten, zoals ERwin, gebruiken de term alternatieve 
sleutel (alternate key of AK) in plaats van kandidaatsleutel. 


WERKNEMER KLANT 


NS Werknemerummer Q Klantnummer 


Naam (AK1.1) 
Plaats (AK1.2) 
Telefoon 

E-mail (AK2.1) 


Werknemernaam 
Telefoon 

E-mail (AK1.1) 
DatumAangenomen 
DatumBeoordeling 
WnCode 


(a) (b) 


Figuur 6-3 Kandidaatsleutels (alternatieve sleutels) weergeven 


Figuur 6-3(a) toont WERKNEMER met Werknemernummer als de primaire sleutel 
en E-mail als een kandidaatsleutel of alternatieve sleutel. Klantnummer is in Figuur 
6-3(b) de primaire sleutel van KLANT en de samenstelling (Naam, Plaats) en E-mail 
zijn beide kandidaatsleutels. De notatie AKn.m betekent dat het om de nè° alterna- 
tieve sleutel gaat, en daarvan de m°* kolom. E-mail is in de tabel WERKNEMER voor- 
zien van het label AKr.r, omdat dit van de eerste alternatieve sleutel de eerste kolom 
is. KLANT heeft twee alternatieve sleutels. De eerste is een samenstelling van twee 
kolommen, die van de labels AKr.r en AKr.2 zijn voorzien. De term Naam (AK1.1) 
betekent dat Naam de eerste kolom van de eerste alternatieve sleutel is, en Plaats 
(AK1.2) betekent dat Plaats de tweede kolom van de eerste alternatieve sleutel is. E- 


mail wordt in KLANT aangegeven als AK2.r, omdat dit de eerste (en enige) kolom 
van de tweede alternatieve sleutel is. 


186 


DATAMODELLEN OMZETTEN IN OATABASEONTWERPEN 


6.2 Eigenschappen van kolommen opgeven 


De volgende stap in het maken van een relatie is het opgeven van de eigenschappen 
van de kolommen. Je ziet vier eigenschappen in Figuur G-r: nullstatus, datatype, de- 
faultwaarde en data constraints. 


6.2.1 NULL of NOT NULL (nullstatus) 

De nullstatus geeft aan of de kolom al dan niet een nullwaarde kan hebben. De null- 
status wordt normaliter opgegeven met het sleutelwoord NULL als nullwaarden zijn 
toegestaan en NOT NULL als dat niet het geval is. NULL betekent dus niet dat de 
kolom altijd null is, maar alleen dat het null mag zijn. Figuur 6-4 toont de nullstatus 
van elk van de kolommen van de tabel WERKNEMER. 


WERKNEMER 


AN Werknemernummer: NOT NULL 


Werknemernaam: NOT NULL 
Telefoon: NULL 

E-mail: NULL (AK1.1) 
DatumAangenomen: NOT NULL 
DatumBeoordeling: NULL 
WnCode: NULL 


Figuur 6-4 Een tabel die de nullstatus aangeeft 


Opmerking 

In WERKNEMER in Figuur 6-4 wordt bij de primaire sleutel NOT NULL aangegeven, terwijl alternatieve 
sleutel E-mail NULL mag zijn. E-mail hoeft geen waarde te hebben. Als E-mail wel een waarde heeft, zal 
deze waarde verschillen van elke andere waarde van E-mail in de tabel WERKNEMER. Zoals je ziet mogen 
de alternatieve sleutels wel eens NULL zijn. 


6.2.2 Het gegevenstype 

De volgende stap is het definiëren van het gegevenstype voor elke kolom. Bijna elk 
DBMS heeft zijn eigen datatypen. Microsoft Access heeft de gegevenstypen Tekst, 
Memo, Numeriek, Datum/tijd, Valuta, Autonummering, Ja/nee, OLE-object, Hyper- 
link, Bijlage en Opzoekkolom. Sommige typen, zoals Numeriek, kennen weer een 
verdere onderverdeling in bijvoorbeeld gehele getallen (Integer of Lange integer) of 
gebroken getallen (Enkele precisie of Dubbele precisie) met een bepaald aantal deci- 
malen. Bij Tekst moet je aangeven wat de maximale veldlengte is. 

Als je weet welk DBMS je zult gebruiken voor het maken van de database, dan 
kun je de datatypen van dat product in jouw ontwerp aangeven. In Figuur 6-5 zie je 
daar een voorbeeld van. 

Veel producten voor het modelleren van gegevens bieden de mogelijkheid op te 
geven welk DBMS je zult gebruiken — het programma zal dan de juiste reeks data- 
typen bieden. We hebben dat in Figuur 6-5 gedaan met ERwin. 
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WERKNEMER 


as Werknemernummer: int 


Werknemernaam: char(50) 
Telefoon: char(15) 

E-mail: char(50) (AK1 .1) 
DatumAangenomen: datetime 
DatumBeoordeling: datetime 
WnCode: char(18) 


Figuur 6-5 Een tabelweergave met de datatypen 


WERKNEMER 


AN Werknemernummer: int NOT NULL 


Werknemernaam: char(50) NOT NULL 
Telefoon: char(15) NULL 

E-mail: char(50) NULL (AK1.1) 
DatumAangenomen: datetime NOT NULL 
DatumBeoordeling: datetime NULL 
WnCode: char(18) NULL 


Figuur 6-6 Een tabelweergave met de nullstatus en de datatypen 


Je kunt de datatypen ook op een algemene manier opgeven, als je niet weet welk 
DBMS-product je zult gebruiken of als je gewoon onafhankelijk wilt blijven van 
een specifiek DBMS. Gebruikelijke algemene datatypen zijn CHAR(n) voor strings 
(reeks van karakters) met de onveranderlijke lengte n, VARCHAR(n) voor strings 
met een variabele lengte en de maximale lengte n, DATE, TIME, MONEY, INTEGER 
en DECIMAL. 

Figuur 6-6 laat de tabel zien met zowel de datatypen als de NULL-status. Om het 
overzichtelijk te houden, geven we de tabellen weer met alleen kolomnamen. De 
meeste producten maken het je mogelijk dergelijke weergaven in of uit te schakelen. 


6.2.3 De defaultwaarde 


Een defaultwaarde is een waarde die het DBMS automatisch kan invoeren als er een 
nieuwe rij wordt toegevoegd. Deze waarde kan een constante zijn, zoals de string 
‘Nieuwe werknemer’ voor de kolom WnCode van WERKNEMER, of de waarde kan 
het resultaat van een functie zijn, zoals de datumwaarde van de ingebouwde klok van 
de computer voor de kolom DatumAangenomen. 

De defaultwaarden zijn in sommige gevallen ook te berekenen met behulp van 
ingewikkelder logica. De defaultwaarde voor een prijs is bijvoorbeeld te berekenen 
door een winstmarge bij een standaardprijs op te tellen en het resultaat dan te ver- 
minderen met de korting voor een klant. In een dergelijk geval wordt er een deel- 
toepassing of een trigger geschreven, die een dergelijke waarde zal leveren. Triggers 
beschrijven we in het volgende hoofdstuk. 

Het is mogelijk om defaultwaarden op te geven met de tool voor het modelle- 
ren van gegevens, maar dergelijke waarden worden vaak in een afzonderlijke ont- 


188 


DATAMOLELLEN OMZETTEN IN DATABASEONTWERPEN 


werpdocumentatie opgenomen. Figuur 6-7 laat een van de manieren zien waarop 
defaultwaarden kunnen worden gedocumenteerd. 


Kolom Defaultwaarde 


ItemNummer surrogate key 
Categorie geen 
 rEM ItemVoorvoegsel als Categorie = ‘bederfelijk’ dan ‘B’ 
als Categorie = ‘geïmporteerd’ dan 'l’ 
als Categorie = ‘eenmalig’ dan ‘E' 
LH anders = ‘'N’ 
it 
ITEM Goedkeurende Afdeling als ItemVoorvoegsel = ‘|’ dan 
‘EXPEDITIE/INKOOP’ 
anders = ‘INKOOP' 
ITEM Verzendwijze als ItemVoorvoegsel = ‘B' dan 
‘Expreszending’ anders = ‘Postzending' 


Figuur 6-7 Voorbeelddocumentatie voor defaultwaarden 


6.2.4 De data constraints 

Data constraints zijn aan gegevenswaarden opgelegde beperkingen. Er zijn diverse 
soorten. Domain constraints beperken kolomwaarden tot op een specifieke verzame- 
ling waarden. WERKNEMER. WnCode kunnen we bijvoorbeeld beperken tot een van 
de volgende waarden: ‘Nieuwe werknemer’, ‘Uurloon’, ‘Salaris’ of ‘Deeltijd’. Range 
constraints beperken waarden tot op een specifiek bereik aan waarden. WERK- 
NEMER.DatumAangenomen kunnen we bijvoorbeeld beperken tot alleen datums 
tussen 1 januari 19go en 31 december 2010. 

Een intrarelation constraint (intrarelatievoorwaarde) legt beperkingen op aan de 
waarden van een kolom, in vergelijking tot de waarden in andere kolommen van 
dezelfde tabel. De voorwaarde dat WERKNEMER.DatumBeoordeling minstens drie 
maanden later moet zijn dan WERKNEMER.DatumAangenomen is een intrarela- 
tion constraint. Interrelation constraints (interrelatievoorwaarden) leggen beperkin- 
gen op aan de waarden van een kolom, in vergelijking tot die in kolommen van 
andere tabellen. Een voorbeeld voor de tabel KLANT is dat KLANT.Naam niet gelijk 
mag zijn aan ZWARTE. _LIJST.Naam, waarbij ZWARTE. LIJST een tabel is die een 
lijst bevat van klanten met krediet- en betalingsproblemen. 

Een referentiële integriteitsvoorwaarde (zie hoofdstuk 3) is een voorbeeld van 
een interrelation constraint. Deze zijn zo algemeen dat ze soms alleen worden 
gedocumenteerd als ze niet worden afgedwongen. Om werk te besparen zal een 
ontwerpteam bijvoorbeeld aannemen dat elke externe sleutel een referentiële inte- 
griteitsvoorwaarde heeft voor de tabel waarnaar deze verwijst en zal het alleen uit- 
zonderingen op deze regel documenteren. 
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6.2.5 Normalisatie controleren 

De laatste taak van de eerste stap in Figuur 6-1 is het controleren van de normalisa- 
tie van de tabel. Je moet je afvragen of de gemaakte tabellen in BCNF zijn en of alle 
meerwaardige afhankelijkheden zijn verwijderd. Is dat niet het geval, dan moeten 
de tabellen waarschijnlijk genormaliseerd worden. Zoals je in hoofdstuk 4 zag, is 
normaliseren niet altijd gewenst. Je moet tabellen daarom ook controleren om te be- 
palen of ze misschien gedenormaliseerd moeten worden. Het resultaat van stap r is 
een verzameling van complete, maar van elkaar onafhankelijke tabellen. 


6.3 Relaties tussen tabellen maken 


Relaties worden over het algemeen gemaakt door externe sleutels in tabellen op te 
nemen. De manier waarop je dat doet en de eigenschappen van de externe sleutel- 
kolommen zijn afhankelijk van het soort relatie. We kijken hier naar elk van de vol- 
gende relaties: sterke entiteitenrelaties, ID-afhankelijke relaties, gemengde relaties, 
relaties tussen super- en subtypen en recursieve relaties. We sluiten dit deel af met 
een bespreking van speciale gevallen van drieledige relaties. 


6.3.1 Relaties tussen sterke entiteiten 


‘Zoals je in hoofdstuk 5 zag, kenmerken sterke entiteitenrelaties zich door hun maxi- 


mumkardinaliteit. De drie soorten sterke entiteitenrelaties zijn 1:1, 1:N en N:M. We 
zullen elk van deze soorten hier bekijken. 


6.3.2 1:1 sterke entiteitenrelaties 

Nadat je de tabellen van de betreffende sterke entiteiten hebt ontworpen, kun je de 
L:I-relatie op twee manieren vormgeven: je neemt de primaire sleutel van de eerste 
tabel in de tweede tabel op, of je neemt de primaire sleutel van de tweede tabel in de 
eerste tabel op. 

Figuur 6-8 toont de representatie van de 1:1 sterke entiteitenrelatie tussen CLUB- 
LID en KASTJE. Lidnummer is in Figuur 6-8(a) in KASTJE opgenomen. Kastnum- 
mer is in Figuur 6-8(b) in CLUBLID opgenomen. 

Beide alternatieven voldoen. In Figuur 6-8(a) kun je met een bepaald Lidnum- 
mer een query op de tabel KASTJE uitvoeren. Omgekeerd, als je een Kastnummer 
hebt kun je via de externe sleutel de gegevens over het clublid opvragen. Voor Figuur 
6-8(b) geldt iets dergelijks. 

Omdat de relatie r:r is, moet voor beide ontwerpen gelden dat de waarden van 
de externe sleutel (FK) uniek zijn. Dit wordt vaak gedaan door de externe sleutel als 
alternatieve sleutel aan te geven. Dat is een beetje verwarrend omdat logisch gezien 
Lidnummer (in Figuur 6-8(a)) geen alternatieve sleutel voor KASTJE is. We doen 

dat alleen maar vanwege de eigenschap dat de waarden van een alternatieve sleutel 
uniek zijn. Hetzelfde geldt voor de externe sleutel in Figuur 6-8(b). 

Hoewel beide ontwerpen voldoen, kan het zo zijn dat de ontwerpers een sterke 
voorkeur hebben voor een van beide, zoals je zult zien in paragraaf 6.9. 
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CLUBLID KASTJE 


Kleedkamer 
Kastgrootte 
Lidnummer (FK) (AK1.1) 


Lidnaam 
Telefoon 
E-mail 


(a) Met externe sleutel in KASTJE 


CLUBLID 


Lidnaam 
Telefoon 
E-mail 

Kastnummer (FK) (AK1.1) 


(b) Met externe sleutel in CLUBLID 
Figuur 6-8 De twee alternatieven voor het representeren van een 1:1 sterke entiteitenrelatie 


6.3.3 1:N sterke entiteitenrelaties 

Nadat je de tabellen van de betreffende sterke entiteiten hebt ontworpen, geef je een 
:N-relatie vorm door de sleutel van de tabel aan de één-kant op te nemen in de tabel 
aan de veel-kant. Je zult nog uit hoofdstuk 5 weten dat de term parent wordt gebruikt 
om naar de tabel aan de één-kant te verwijzen en de term child om naar de tabel aan 
de veel-kant te verwijzen. Je kunt het ontwerp van r:N-relaties samenvatten met deze 
terminologie door te zeggen dat de sleutel van de parent in de child moet worden 
opgenomen. 

Figuur 6-g(a) laat een E-R-diagram zien voor de r:N-relatie tussen BEDRIJF en 
AFDELING. Deze relatie wordt in Figuur 6-9(b) gerepresenteerd door de sleutel van 
de parent (Bedrijfsnaam) in de child op te nemen. Het is niet nodig de externe sleutel 
uniek te maken, want parents kunnen veel children hebben (de relatie is r:N). 

Dat is alles wat je moet weten over r:N-relaties tussen sterke entiteiten. Je moet 
alleen het volgende onthouden: plaats de primaire sleutel van de parent in de child 
als een externe sleutel. 


6.3.4 N:M sterke entiteitenrelaties 

De situatie is ingewikkelder voor N:M-relaties. Het probleem is dat er in een N:M- 
relatie in geen van de beide tabellen een plaats is waar de externe sleutel kan worden 
opgenomen. Kijk bijvoorbeeld eens naar Figuur G-ro(a), die een relatie laat zien die 
opgeeft welke bedrijven welke onderdelen kunnen leveren. Een BEDRIJF kan veel 


onderdelen leveren en een ONDERDEEL kan door veel verschillende bedrijven wor- 
den geleverd. 
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BEDRIJF AFDELING 


h 
| 
Ì 
H 
| 


(a) 1:N sterke entiteitenrelatie 


Bedrijfsnaam 


Plaats 
Land 
Volume 


BEDRIJF AFDELING 


eN Bedrijfsnaam 


Plaats 
Land 
Volume 


Budgetcode 
Postbus 
Bedrijfsnaam (FK) 


(b) De sleutel van de parent wordt in de child opgenomen 


Figuur 6-9 Een 1:N sterke relatie representeren 


BEDRIJF ONDERDEEL 


\ Bedrijfsnaam 


Plaats 
Land 
Volume 


Onderdeelnaam 
Verkoopprijs 

AantalBestellen 
AantalOpVoorraad 


(a) Er is in geen van beide tabellen ruimte voor een 
externe steutel 


BEDRIJF ONDERDEEL 


EN Bedrijfsnaam EN Onderdeelnummer 


Plaats Onderdeelnaam 
Land Verkoopprijs 
Volume AantalBestellen 


AantalOpVoorraad 


BEDRIJF ONDERDEEL INT 


(b) Plaats beide externe sleutels in een 
ID-afhankelijke intersectietabel 


Figuur 6-10 Een N:M sterke entiteitenrelatie representeren 
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Stel dat we proberen deze relatie te representeren door de primaire sleutel van de 
ene tabel als een externe sleutel in de tweede tabel op te nemen, zoals we dat voor 
:N-relaties deden. Laten we zeggen dat we de primaire sleutel van ONDERDEEL als 
volgt in BEDRIJF opnemen: 


BEDRIJF (Bedrijfsnaam, Plaats, Land, Volume, Onderdeelnummer) 
ONDERDEEL (Onderdeelnummer, Onderdeelnaam, Verkoopprijs, 
AantalNabestellen, AantalOpVoorraad) 


Dit ontwerp heeft tot gevolg dat als een bepaald bedrijf veel onderdelen levert de ge- 
gevens van dat bedrijf telkens herhaald moeten worden in de tabel. Dit leidt tot onac- 
ceptabele gegevensduplicatie en de bijbehorende integriteitsproblemen. 

Hetzelfde soort overwegingen geldt als je de primaire sleutel van BEDRIJF als 
een externe sleutel in ONDERDEEL opneemt, als een bepaald onderdeel door veel 
verschillende bedrijven geleverd wordt. 

De oplossing is het maken van een derde tabel, die een intersectietabel (tussen- 
tabel) wordt genoemd. Een dergelijke tabel geeft de verbindingen aan tussen een ge- 
geven bedrijf en een gegeven onderdeel. Deze tabel bevat alleen externe sleutels — de 
tabel bevat geen gebruikersgegevens. We maken de volgende intersectietabel voor 
het voorbeeld uit Figuur 6-ro(a): 


BEDRIJF ONDERDEEL (Bedrijfsnaam, Onderdeelnummer) 


Deze tabel heeft een rij voor elke combinatie van een bedrijf en een onderdeel. Merk 
op dat beide kolommen deel uitmaken van de primaire sleutel en dat elke kolom een 
externe sleutel is naar een andere tabel. Tussentabellen zijn altijd [D-afhankelijk van 
hun beide parent-tabellen, omdat beide kolommen sleutels zijn van andere tabellen. 

Er wordt daarom in Figuur 6-ro(b) aangegeven dat BEDRIJF_ONDERDEEL ID- 
afhankelijk is. De parent-tabellen zijn vereist, zoals dat bij alle ID-afhankelijke ta- 
bellen het geval is — BEDRIJF ONDERDEEL vereist zowel een BEDRIJF als een 
ONDERDEEL. De parents kunnen al dan niet vereisen dat er een rij in de intersec- 
tietabel voorkomt — dat is afhankelijk van de toepassingseisen. Een BEDRIJF hoeft 
in Figuur 6-ro(b) geen ONDERDEEL te leveren, maar een ONDERDEEL moet door 
minstens één BEDRIJF worden geleverd. 


Opmerking 

Het probleem bij het ontwerpen van N:M sterke entiteitenrelaties is dat deze niet op een rechtstreekse 
manier kunnen worden gerepresenteerd. Een N:M-relatie moet altijd met behulp van een tussentabel 
worden ontleed in twee 1:N-relaties. 


6.4 Relaties met ID-afhankelijke entiteiten 


Er is een aantal situaties waarin relaties met ID-afhankelijke entiteiten een rol spe- 


len. Een daarvan hebben we zojuist besproken: voor het representeren van een N:M 
sterke entiteitenrelatie. 
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Twee andere situaties die al in hoofdstuk 5 ter sprake kwamen, zijn associatierelaties 
en relaties met meerwaardige attributen. We beschrijven hier hoe relaties voor deze 
gevallen worden ontworpen. 


6.4.1 Associatierelaties 

Je zult je uit hoofdstuk 5 herinneren dat associatierelaties veel op N:M sterke entitei- 
tenrelaties lijken. Het enige verschil tussen deze twee soorten relaties is dat een as- 
sociatierelatie een of meer attributen heeft die op de relatie zelf van toepassing zijn, 
in plaats van op een van de entiteiten. Figuur 6-11(a) is een kopie van de in Figuur 
5-16 gemaakte associatierelatie. De associatie van een bedrijf en een onderdeel heeft 
in dat voorbeeld een attribuut met de naam Prijs. 


ONDERDEEL BEDRIJF 


Bedrijfsnaam i 


Plaats 
Land 
Volume 


Onderdeelnaam 
Verkoopprijs 

AantalVoorNabestellen 
Aa 


PRIJSOPGAVE 


Onderdeelnummer _ | 
Bedrijfsnaam 


| 
| 
Ï 
} 


(a) Het E-R-model uit figuur 5.16 


ONDERDEEL BEDRIJF 


Plaats 
Land 
Volume 


Onderdeelnaam 
Verkoopprijs 

AantalVoorNabestellen 
AantalOpVoorraad 


PRIJSOPGAVE 


(b) Tabellen die de entiteiten representeren 


figuur 6-11 1D-afhankelijke entiteiten gebruiken voor een associatierelatie 
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Een dergelijke relatie is makkelijk te representeren met een tabel. Maak gewoon een 
tabel die [D-afhankelijk is van de beide parents en neem het attribuut Prijs in die ta- 
bel op. Dat resulteert voor het voorbeeld uit Figuur 6-1r(a) in de tabel: 


PRIJSOPGAVE (Bedrijfsnaam, Onderdeelnummer, Prijs) 


De parents van een associatierelatie zijn vereist — zoals dat bij alle ID-afhankelijke 
relaties het geval is. De parents kunnen al dan niet rijen in de associatietabel verei- 
sen, afhankelijk van de toepassingseisen. Een BEDRIJF hoeft in Figuur 6-1r(b) geen 
PRIJSOPGAVE-rijen te hebben, maar een ONDERDEEL moet minstens één PRIJS- 
OPGAVE-rij hebben. 


Opmerking 

De tabel die de associatie weergeeft, lijkt erg veel op een tussentabel. Het enige verschil is de 
aanwezigheid van Prijs. Vanwege dit attribuut ontstaat vanuit de gebruikerseisen de noodzaak voor een 
associatietabel als PRIJSOPGAVE. Ergens zal een formulier of rapport zijn waarin het attribuut Prijs een rol 
speelt. 

Een tussentabel speelt in de wereld van gebruikers nooit een rol. Ze zijn het gevolg van het relationele 
model en komen in formulieren of rapporten niet voor. Associatietabellen bevatten gegevens van 
gebruikers, tussentabellen nooit. 


Associatie-entiteiten koppelen soms meer dan twee soorten entiteiten aan elkaar. Fi- 
guur 6-1a(a), die een kopie is van Figuur 5-17, toont een associatie van de entiteiten 
CLIËNT, ARCHITECT en PROJECT. De zojuist besproken strategie wordt simpel- 
weg uitgebreid als er meer entiteiten aan de associatie deelnemen. Zoals je in Fi- 
guur 6-12(b) ziet, zal de associatietabel de sleutel van elk van zijn parents bevatten. 
De tabel TOEKENNING heeft in dit geval drie externe sleutels en een attribuut dat 
geen sleutel is: UrenGewerkt. 

Het is overigens toeval dat de associatietabellen van deze voorbeelden allebei 
maar één attribuut bevatten dat geen sleutel is. Een associatietabel kan over het alge- 
meen zoveel attributen bevatten die geen sleutels zijn als er maar nodig zijn om aan 
de gebruikerseisen te voldoen. 


6.4.2 Meerwaardige attributen 
In Figuur 6-13(a) heeft BEDRIJF een meerwaardige samenstelling (Contactper- 


soon, Telefoonnummer), die wordt gerepresenteerd door de 1D-afhankelijke entiteit 
TELEFOONCONTACT. 


TELEFOONCONTACT kan makkelijk worden gerepresenteerd. Vervang dit ge- 
woon door een tabel en vervang elk van de attributen ervan door een kolom. Het 


attribuut Contactpersoon is in dit voorbeeld zowel een onderdeel van de primaire 
sleutel als een externe sleutel. 


8 TELEFOONCONTACT moet, zoals alle ID-afhankelijke entiteiten, een parent- 
ri hebben in BEDRIJF. Een rij in BEDRIJF kan aan de andere kant al dan niet een 
vereist TELEFOONCONTACT hebben. Dat is afhankelijk van de toepassingseisen. 
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CLIËNT ARCHITECT 


lefoon TOEKENNING 


5 EE 


Cliëntnaam 
old Architectnaam 
Projectnaam 


(a) Het E-R-model uit figuur 5.17 


CLIËNT ARCHITECT 


AN Cliëntnaam 
aN Architectnaam 
aN Projectnaam 


(b) Tabellen die de entiteiten representeren 


Figuur 6-12 Een associatierelatie tussen drie entiteiten 
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BEDRIJF2 BEDRIJF2 


aN Bedrijfsnaam 


Plaats 
Land 
Volume 


Bedrijfsnaam 


Plaats 
Land 
Volume 


TELEFOONCONTACT TELEFOONCONTACT 


(a) E-R-model met (b) Tabellen die de 
meerwaardige attributen entiteiten representeren 


Figuur 6-13 ID-afhankelijke entiteiten gebruiken voor meerwaardige attributen 


6.5 Relaties tussen super- en subtypen 


Relaties tussen super- en subtypen zijn makkelijk te representeren. Je zult je herin- 
neren dat een subtyperelatie ook wel een IS-EEN-relatie heet, omdat een subtype en 
zijn supertype beide versies van dezelfde basisentiteit zijn. Een MANAGER (sub- 
type) is een WERKNEMER, en een VERKOPER (subtype) is ook een WERKNEMER. 
De sleutels van de subtypetabellen zijn vanwege deze gelijkwaardigheid allemaal 
identiek aan de sleutel van de supertypetabel. 


STUDENT STUDENT 


StudentlD 


Achternaam 
Voornaam 
IsPostDoc 


Achternaam 
Voornaam 
IsPostDoc 


IsPostDoc 


DOCTORAAL POSTDOCTORAAL DOCTORAAL POSTDOCTORAAL 


StudentiD StudentlD eN StudentlD (FK) as StudentiD (FK) 


EindexGem DoctoraalGem EindexGem DoctoraalGem 
ToelatingsScore GemResultaat 


(a) Het supertype/subtype van Figuur 5-13(a) (b) De tabelrepresentatie 


GemResultaat ToelatingsScore 


Figuur 6-14 Subtypen representeren 
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Figuur G-14(a), die een kopie is van Figuur 5-13(a), laat een voorbeeld zien van twee 
subtypen van STUDENT. Merk op dat STUDENT de sleutel StudentID heeft en dat 
de sleutel van elk subtype ook StudentID is. DOCTORAAL.StudentID en POST- 
DOCTORAAL.StudentID zijn zowel primaire sleutels als externe sleutels naar hun 
supertype. 

Discriminatorattributen kunnen niet worden gerepresenteerd in relationele ont- 
werpen. We kunnen in Figuur 6-14(b) niets met isPostDoc doen — we kunnen alleen 
in de ontwerpdocumentatie opmerken dat isPostDoc het subtype bepaalt. We zullen 
toepassingsprogramma’s moeten schrijven die isPostDoc gebruiken om te bepalen 
welk subtype bij welke WERKNEMER hoort. 


6.6 Recursieve relaties 


Als een entiteit een relatie naar zichzelf heeft, heet dat een recursieve relatie. Er zijn, 
net als bij sterke entiteiten, drie soorten recursieve relaties mogelijk: r:1, r:N en N:M. 

We kunnen recursieve relaties representeren door de technieken voor het repre- 
senteren van sterke entiteiten uit te breiden. Deze technieken kunnen in eerste in- 


stantie wat moeilijk te begrijpen zijn omdat ze vreemd lijken, maar ze zijn gebaseerd 
op principes die je al kent. 


6.6.1 1:1 recursieve relaties 

Bekijk eens de relatie tussen de wagons van een goederentrein. Elke goederenwagon, 
behalve de eerste, heeft een wagon voor zich, en elke goederenwagon, behalve de 
laatste, heeft een wagon achter zich. Het is dus een r:1-relatie met een optionele rela- 
tie voor de eerste en de laatste wagon. 

Kijk eens naar de r:1 recursieve GOEDERENWAGON-relatie in Figuur 6-15(a). 
We representeren deze relatie door een externe sleutel aan GOEDERENWAGON 
toe te voegen die de identifier van de voorafgaande vrachtwagon bevat, zoals je dat in 
Figuur 6-15(b) ziet. We maken de externe sleutel uniek door deze als een alternatieve 
sleutel te definiëren, omdat de relatie 1:1 is. Deze beperking zorgt ervoor dat een goe- 
derenwagon maximaal één wagon voor zich kan hebben. 


Merk op dat beide kanten van deze relatie optioneel zijn. Dat komt omdat de laatste 
wagon in de trein zich niet voor een andere wagon bevindt en omdat de eerste wagon 
in de trein geen andere wagon voor zich heeft. Deze beperking zou niet nodig zijn 
als de gegevensstructuur rond zou lopen. Wil je bijvoorbeeld de reeks namen van ka- 
lendermaanden representeren en wil je dat december naar januari leidt, dan heb je 
een 1:1 recursieve structuur met vereiste children. 


6.6.2 1:N recursieve relaties 

Het klassieke voorbeeld van een r:N recursieve relatie doet zich voor in organisaties 
waarin een bepaalde manager een WERKNEMER is die de manager is van andere 
WERKNEMERS. 
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LOCOMOTIEF 


Model 
AantalPK 


° 


‚ EersteWagon 
2 


VRACHTWAGON 


Vrachtwagonnr 


Laadvermogen 
Model 


Voorgaande wagon 


(a) Datamodel voor een 1:1 


recursieve relatie 


Figuur 6-15 1:1 recursieve relaties representeren 


WERKNEMER 


Manager van 


(a) Datamodel voor een 1:N 


recursieve relatie 


Figuur 6-16 1:N recursieve relaties representeren 
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LOCOMOTIEF 


Loenummer 


Model 
AantalPK 


o 


‚ EersteWagon 
©) 


VRACHTWAGON 


SQ Vrachtwagonnr 


Laadvermogen 
Model 
WagonnrVoor (FK) (AK1.1) 


Voorgaande wagon 


(b) Databaseontwerp voor een 1:1 
recursieve relatie 


WERKNEMER 


Manager van 


(b) Databaseontwerp voor een 1:N 


recursieve relatie 


Figuur 6-16(a) toont het datamodel voor de relatie tussen manager en werknemers. 
De relatie is optioneel omdat een manager (de directeur) geen manager heeft, en er 
werknemers zijn die geen leiding geven. 

IN recursieve relaties worden, net als alle 1:N-relaties, gerepresenteerd door de 
sleutel van de parent in de child op te nemen. Dat betekent voor de relatie ‘Manager 
van’ uit Figuur 6-16(a) dat we de naam van de manager in de tabel WERKNEMER 


opnemen, zoals in Figuur 6-16(b). 


6.6.3 N:M recursieve relaties 


De truc voor het representeren van N:M recursieve relaties bestaat eruit de N:M-rela- 
tie in twee r:N-relaties te ontleden. We doen dat door een tussentabel te maken, net 
zoals we dat deden voor N:M-relaties tussen sterke entiteiten. 
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ONDERDEEL ONDERDEEL 
Onderdeelnaam 


' eN Onderdeelnaam 


Overige gegevens 


Bevat onderdeel Is_onderdeel van 


Î 
| ONDERDEEL ONDERDEEL D5 


SOnderdeelnaam (FK) À 
Ì SBevatOnderdeelnaam (po 


LS 


(a) Het N:M recursieve model (b) De tabelweergave 


LS 


Figuur 6-17 N:M recursieve relaties representeren 


Figuur 6-17(a) laat een voorbeeld zien van een materiaallijst. Elk onderdeel heeft mo- 
gelijk veel subonderdelen en kan mogelijk als een onderdeel worden gebruikt in veel 
andere onderdelen. 

We representeren deze relatie door een tussentabel te maken die de overeen- 
komst aangeeft tussen onderdelen en het gebruik van onderdelen. Je kunt naar 
boven of naar beneden modelleren. De intersectietabel zal in het eerste geval de 
overeenkomst aangeven tussen een onderdeel en de onderdelen waar dat onderdeel 
in gebruikt wordt. De intersectietabel zal in het tweede geval de overeenkomst aan- 
geven tussen een onderdeel en alle onderdelen die in dat onderdeel gebruikt wor- 


den. Figuur 6-17(b) toont de intersectietabel voor het naar beneden modelleren in de 
materiaallijst. 


6.7 Relaties met drie en meer leden representeren 


Zoals we al in hoofdstuk 5 vermeldden, zijn relaties met drie en meer leden te re- 
presenteren met behulp van een aantal binaire relaties. Dergelijke representaties 
werken meestal probleemloos. Er zijn in sommige gevallen echter voorwaarden die 
de zaak ingewikkelder maken. Neem bijvoorbeeld de drieledige relatie tussen BE- 
STELLING, KLANT en VERKOPER. Neem aan dat de relatie van KLANT tot BE- 
STELLING r:N is en dat de relatie van VERKOPER tot BESTELLING ook r:N is. We 
kunnen de drieledige relatie tussen BESTELLING:KLANT:VERKOPER represente- 
ren als twee afzonderlijke binaire relaties — de ene tussen BESTELLING en KLANT 
en de andere tussen VERKOPER en KLANT. Het ontwerp van de tabellen zal er als 
volgt uitzien: 


KLANT (Klantnummer, attributen die geen sleutels zijn) 

VERKOPER (Verkopernummer, attributen die geen sleutels zijn) 

BESTELLING (Bestelnummer, attributen die geen sleutels zijn, 
Klantnummer, Verkopernummer) 
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Stel nu dat het bedrijf een regel heeft die bepaalt dat elke KLANT alleen be- 
stellingen kan plaatsen bij een bepaalde VERKOPER. De drieledige relatie 
BESTELLING:KLANT:VERKOPER wordt in dat geval beperkt door een extra r:N- 
relatie tussen VERKOPER en KLANT. We moeten de sleutel van VERKOPER aan 
KLANT toevoegen om deze voorwaarde te representeren. De drie relaties zien er nu 
zo uit: 


KLANT (Klantnummer, attributen die geen sleutels zijn, 

Verkopernummer) 
VERKOPER (Verkopernummer, attributen die geen sleutels zijn) 
BESTELLING (Bestelnummer, attributen die geen sleutels zijn, 


Klantnummer, Verkopernummer) 


De voorwaarde dat een bepaalde KLANT alleen bij een bepaalde VERKOPER kan 
bestellen, betekent dat alleen bepaalde combinaties van Klantnummer en Verkoper- 
nummer kunnen voorkomen in BESTELLING. Deze voorwaarde kan echter jammer 
genoeg niet worden uitgedrukt in een relationeel model. De voorwaarde moet echter 
in het ontwerp worden gedocumenteerd en door programmacode worden gehand- 
haafd. Zie Figuur 6-18. 


De tabel VERKOPER 
Overige gegevens die 


EE 


Verkopernummer 
TOE Me Te 


Klantnummer Overige gegevens die | Verkopernummer 
geen sleutels zijn 


SOR 
k ) 
Dn Binaire MOET-voorwaarde 


De tabel BESTELLING 
Bestelnummer Overige gegevens die | Verkopernummer Klantnummer 
geen sleutels zijn 


NT 
Hier is alleen 20 toegestaan 
Figuur 6-18 Een drieledige relatie met een MOET-voorwaarde 
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Een voorwaarde die een combinatie vereist van een entiteit met een andere entiteit, 
wordt een MOET-ofeen MUST-voorwaarde genoemd. Andere dergelijke voorwaarden 
zijn MAG NIET (MUST NOT) en MOET OMVATTEN (MUST COVER). De binaire 
relatie geeft bij een MAG NIET-voorwaarde aan welke combinaties niet in de driele- 
dige relaties mogen voorkomen. De drieledige relatie RECEPT:MEDICIJN:KLANT 
kan bijvoorbeeld beperkt worden door een binaire relatie in de tabel ALLERGIE die 
een lijst bevat van medicijnen die een klant niet mag innemen. Zie Figuur 6-19. 


De tabel MEDICIJN 


Overige gegevens die 
geen sleutels zijn 


4 
E Binaire MAG NIET-voorwaarde 2) 


De tabel RECEPT 
Receptnummer Overige gegevens die | Medicijnnummer Klantnummer 
geen sleutels zijn 
100 Ee 1000 
EE 2000 
SOON VOS {1000 
ZOOMEN 20E eer {3000 
SOON EKE [2000 


Hier mag geen 20 of 45 staan 


Figuur 6-19 Een drieledige relatie met een MAG NIET-voorwaarde 


Bij een MOET OMVATTEN-voorwaarde geeft de binaire relatie alle combinaties 
aan die in de drieledige relatie moeten voorkomen. Neem bijvoorbeeld de relatie 
AUTO:REPARATIE:TAAK. Stel dat een gegeven REPARATIE uit een aantal taken 
bestaat, die allemaal moeten worden uitgevoerd om de reparatie te laten slagen. 
Alle taken voor een gegeven REPARATIE moeten in dat geval als rijen in de relatie 
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AUTO-REPARATIE voorkomen als een gegeven AUTO deze REPARATIE onder- 
gaat. Zie Figuur 6-20. 


De tabel REPARATIE 


Reparatienummer 


Overige gegevens die 
geen sleutels zijn 


Overige gegevens die 
geen sleutels zijn 


Reparatienummer 


10, 
10 SE 
20 
20 En 


dd Binaire MOET OMVATTEN-voorwaarde 
De tabel AUTO-REPARATIE 


Hier moet 2002 staan 


Figuur 6-20 Een drieledige relatie met een MOET OMVATTEN-voorwaarde 


De drie soorten binaire voorwaarden die hier zijn besproken, kunnen geen van alle 
in het relationele ontwerp worden gerepresenteerd. In plaats daarvan worden ze in 
het ontwerp gedocumenteerd en met behulp van toepassingscode geïmplementeerd. 


6.8 De relationele representatie van het datamodel voor de 
universiteit van Leiderhoven 


Laten we het datamodel voor de universiteit van Leiderhoven dat we in het vorige 
hoofdstuk maakten, gebruiken om de principes uit dit hoofdstuk toe te passen en 
een ontwerp voor een database te maken. In Figuur G-21 zie je het datamodel, een 
kopie van Figuur 5-27. 
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FACULTEIT VAKGROEP PROFESSOR 


ProfessorVoornaam 
ProfessorAchternaam 


Gebouw 
Kantoornummer 
Telefoon 


Faculteitnaam Vakgroepnaam Zit voor/ 


Voorgezeten_door 


Telefoon 
AantalAfstuderenden 
Gebouw 

Kamer 


DecaanVoornaam 
DecaanAchternaam 
Telefoon 
Gebouw 
Kamer 


Û 
BENOEMING 


Hoofdvak 


9 


STUDENT 


Studentnummer 


StudentVoornaam 
StudentAchternaamh, O0 
HuisadresStraat Begeleidt/Wordt 
HuisadresPlaats begeleid door 
HuisadresProvincie 


Î 
) 
| 
Titel 
ij 
| 
ij 


HuisadresPostcode 
Telefoon 


Figuur 6-21 Datamodel voor de universiteit van Leiderhoven uit figuur 5-27 


Figuur 6-22 toont het ontwerp voor de database. Bekijk deze figuur goed en wees 
er zeker van dat je begrijpt hoe elke relatie wordt gerepresenteerd. Merk op dat Vak- 
groepnaam tweemaal als externe sleutel wordt opgenomen in de tabel STUDENT. 
Eenmaal om de relatie Hoofdvak tussen STUDENT en VAKGROEP te represente- 
ren. Deze relatie moet voldoen aan de referentiële integriteitsvoorwaarde: 


Vakgroepnaam in STUDENT moet voorkomen in 
Vakgroepnaam in VAKGROEP 


Vakgroepnaam komt een tweede keer voor als onderdeel van de samengestelde sleu- 
tel (ProfessorVakgroepnaam, ProfessorVoornaam, ProfessorAchternaam), die de ex- 
terne sleutel is voor de relatie Begeleidt tussen BENOEMING en STUDENT. Deze 
externe sleutel is gekoppeld aan de primaire sleutel van BENOEMING. Deze relatie 
heeft de volgende referentiële integriteitsvoorwaarde: 


(ProfessorVakgroepnaam, ProfessorVoornaam, ProfessorAchternaam) 
in STUDENT moet voorkomen in 
(ProfessorVakgroepnaam, ProfessorVoornaam, ProfessorAchternaam) 


in BENOEMING 
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FACULTEIT VAKGROEP PROFESSOR 


S Faculteitnaam CN Vakgroepnaam 


on 
Voorgezeten door 


an ProfessorVoornaam 
AN ProfessorAchternaam 


DecaanVoornaam Telefoon 

DecaanAchternaam AantalAfstuderenden Gebouw 
Telefoon Kamer Kantoornummer 
Gebouw Faculteitnaam (FK) Telefoon 


Kamer ProfessorVoornaam (FK) (AK1.1) 


ProfessorAchternaam (FK) (AK1.1) 


/ / 
Hoofdvak \ BENOEMING 
Î eN Vakgroepnaam (FK) 
STUDENT | AN ProfessorVoornaam (FK) 
IN ProfessorAchternaam (FK) 


aN Studentnummer 


Titel 
Voorwaarden 


Titel 
Opmerking: Vakgroepnaam Vakgroepnaam (FK) 
komt geen twee keer voor StudentVoornaam 
wegens een door ERwin StudentAchternaam ï 
gemaakte fout. HuisadresStraat i 
Vakgroepnaam hoort twee HuisadresPlaats LE B lei 
keer voor te komen — HuisadresProvincie Bane 
eenmaal voor de relatie HuisadresPostcode 
Hoofdvak en eenmaal voor Telefoon 
de relatie Begeleidt. ProfessorVoornaam (FK) 

ProfessorAchternaam (FK) 


Figuur 6-22 Een tabelontwerp voor het model voor de universiteit van Leiderhoven uit figuur 5-27 


6.9 Het vastleggen van minimumkardinaliteiten 


De derde en laatste stap in het omzetten van een datamodel in een databaseontwerp, 
is het opstellen van een plan voor het handhaven van de minimumkardinaliteiten. 
Deze stap kan helaas aanzienlijk ingewikkelder zijn dan de eerste twee stappen. Re- 
laties met vereiste children zijn vooral problematisch, want we kunnen dergelijke 
voorwaarden niet afdwingen met databasestructuren. We moeten in plaats daarvan 
procedures ontwerpen die door het DBMS of door applicaties worden uitgevoerd. 
Relaties kunnen een van vier minimumkardinaliteiten hebben: 

* parent optioneel en child optioneel (O-O) 

* parent verplicht (mandatory) en child optioneel (M-O) 

* parent optioneel en child verplicht (O-M) 

* parent verplicht en child verplicht (M-M). 


Er hoeven geen acties te worden ondernomen voor het afdwingen van de minimum- 
kardinaliteit van O-O-relaties en we hoeven daar verder dan ook geen aandacht aan 
te besteden. De overige drie relaties leggen beperkingen op aan activiteiten voor in- 
voegen, bijwerken en verwijderen. 


Figuur 6-23 vat de acties samen die nodig zijn voor het afdwingen van de minimum- 
kardinaliteit. Figuur 6-23(a) laat zien welke acties nodig zijn als de parent-rij verplicht 
is (M-O- en M-M-relaties). Figuur 6-23(b) laat zien welke acties nodig zijn als de 
child-rij verplicht is (O-M- en M-M-relaties). Met actie bedoelen we in deze figuren en 
de volgende bespreking een actie voor het afdwingen van de minimumkardinaliteit. 
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Actie op parent Actie op child 


Invoegen ° koppel aan een parent 
* verbied 


° in orde als de nieuwe 
externe sleutelwaarde 
overeenkomt met een 
bestaande parent 


Sleutel of externe 
sleutel wijzigen 


e wijzig de externe sleutel- 
waarden van de children 
zodat deze overeenkomen 
met de nieuwe waarde 
(cascading update) 

e verbied 


Verwijderen e verwijder de children 
(cascading deletion) 


e verbied 


(a) Acties als de parent vereist is 


Child vereist Actie op parent Actie op child 


Invoegen e koppel aan een child 
e verbied 


Sleutel of externe e werk de externe sleutel bij | e in orde, mits dit niet de 
sleutel wijzigen van (minstens één) kind laatste child is 
verbied verbied of zoek een 
vervanger als dit de laatste 
child is 


Verwijderen e in orde, mits dit niet de 
laatste child is 
e verbied of zoek een 
vervanger als dit de laatste 
child is 


(b) Acties als de child vereist is 
Figuur 6-23 Samenvatting van de acties voor het handhaven van de minimumkardinaliteit 


Om deze regels te bespreken gebruiken we het ontwerp van een database voor 
het opslaan van gegevens van verschillende bedrijven, zie Figuur 6-24. In dit dia- 
gram hebben we een r:N M-O-relatie tussen BEDRIJF en AFDELING, en tussen 
AFDELING en WERKNEMER. Verder een r:N M-M-relatie tussen BEDRIJF en 
TELEFOONCONTACT. 
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BEDRIJF AFDELING 


IN Bedrijfsnaam aN Afdelingnaam 


Plaats 
Land 
Volume 


Budgetcode 
Postbus 
Bedrijfsnaam (FK) 


TELEFOON CONTACT WERKNEMER 


on Contact 
oN Bedrijfsnaam (FK) 


AN Werknemernummer 


Werknemernaam 
Telefoon 
E-mail (AK1.1) 


Telefoonnummer 


DatumAangenomen 
DatumBeoordeling 
WnCode 
Afdelingnaam (FK) 


Figuur 6-24 Het ontwerp van een database voor het opslaan van gegevens van verschillende bedrijven 


In de relatie tussen BEDRIJF en AFDELING is BEDRIJF de parent en AFDELING 
de child. 

In de relatie tussen AFDELING en WERKNEMER is AFDELING de parent en 
WERKNEMER de child. 

In de relatie tussen BEDRIJF en TELEFOONCONTACT is BEDRIJF de parent en 
TELEFOONCONTACT de child. 


6.9.1 Acties als de parent vereist is 

Als de parent vereist is, moeten we ervoor zorgen dat elke rij van de child-tabel een 
geldige waarde voor de externe sleutel heeft die NIET NULL is. We moeten daartoe 
beperkingen opleggen aan de acties voor het bijwerken of verwijderen van de primai- 
re sleutel van de parent en aan de acties voor het maken of wijzigen van de externe 
sleutel van de child. We kijken om te beginnen naar de acties voor de parent. 


6.9.2 Acties op de parent-rij als de parent vereist is 

Er hoeft volgens Figuur 6-23(a) niets te worden gedaan als er een nieuwe parent 
wordt gemaakt. Er kan nog geen child-rij afhankelijk zijn van de nieuwe rij. We kun- 
nen in ons voorbeeld een nieuwe AFDELING maken, zonder ons druk te hoeven 
maken over de minimumkardinaliteit. 

Maar stel je nu eens voor wat er gebeurt als we proberen de waarde van een be- 
staande primaire sleutelrij van de parent te veranderen. Als deze rij children heeft, 
dan zullen deze children een externe sleutelwaarde hebben die overeenkomt met 
de oude waarde van de primaire sleutel. Alle eventuele children zullen ouderloos 
worden als de primaire sleutel van de parent verandert. De externe sleutelwaarden 
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zullen moeten worden veranderd zodat ze overeenkomen met de nieuwe waarde van 
de primaire sleutel van de parent, of het wijzigen van de primaire sleutel van de pa- 
rent zal verboden moeten worden om ouderloze kinderen te voorkomen. 

Als een AFDELING in ons voorbeeld mocht proberen haar Afdelingnaam van 
‘Infosys’ in ‘Informatiesystemen’ te veranderen, dan zullen alle child-rijen met de 
externe sleutelwaarde ‘Info Sys’ geen ouder meer hebben en weeskinderen wor- 
den. Om weeskinderen te voorkomen, moet óf het wijzigen van de primaire sleutel 
van AFDELING verboden worden, óf de waarden van de externe sleutel van WERK- 
NEMER moeten ook in ‘Informatiesystemen’ worden veranderd. 

Het doorgeven van een wijziging van de primaire sleutel van de parent naar de 
externe sleutel van de child noemen we cascading update (trapsgewijze wijziging). 

Stel je nu eens voor wat er gebeurt als we proberen een parent te verwijderen. 
Als de rij children heeft en de verwijdering is toegestaan, dan zullen deze children 
ouderloos worden. Om dat te voorkomen moet verwijdering worden verboden, of de 

children moeten ook worden verwijderd. Het samen met de parent verwijderen van 
de children noemen we cascading deletion (trapsgewijze verwijdering). 

In ons voorbeeld betekent het dat als wordt geprobeerd een AFDELING te verwij- 
deren, dat alle gerelateerde rijen in WERKNEMER ook moeten worden verwijderd, 
of de verwijdering moet geweigerd worden. 


Opmerking 

Voor relaties tussen sterke entiteiten wordt over het algemeen niet voor cascading deletion gekozen. 
Het verwijderen van een rij van AFDELING mag er niet toe leiden dat we rijen uit WERKNEMER moeten 
verwijderen. In plaats daarvan moet de verwijdering worden geweigerd. Moet er een rij uit AFDELING 
worden verwijderd, dan zullen de rijen van WERKNEMER eerst aan een andere AFDELING worden 
toegekend, waarna de rij vit AFDELING kan worden verwijderd. 

Voor zwakke child-entiteiten echter wordt vrijwel altijd voor cascading deletion gekozen. je zult 
bijvoorbeeld de zwakke TELEFOONNUMMER-rijen die van een bedrijf afhankelijk zijn, ook allemaal 
verwijderen als je het BEDRIJF verwijdert. 


6.9.3 Acties op de child-rij als de parent vereist is 

Laten we nu eens naar acties op de child-rij kijken. Als er een nieuwe child-rij wordt 
gemaakt en de parent is vereist, dan zal de nieuwe child-rij een geldige externe sleu- 
telwaarde moeten hebben. De nieuwe WERKNEMER-rij zal een geldige waarde 
moeten hebben voor Afdelingnaam als we een nieuwe WERKNEMER maken en 
AFDELING vereist is. De invoegbewerking moet geweigerd worden als dat niet het 
geval is. Er is meestal een standaardbeleid voor het toekennen van parents aan nieu- 
we rijen. Het standaardbeleid zou in ons voorbeeld kunnen bestaan uit het toevoe- 
gen van een nieuwe werknemer aan een afdeling met de naam ‘Personeel’ als er een 
nieuwe rij aan WERKNEMER wordt toegevoegd. 

Als er een wijziging wordt uitgevoerd in de externe sleutel, dan zal de nieuwe 
waarde overeen moeten komen met een bestaande waarde in de primaire sleutel van 
de parent. Er moet bijvoorbeeld al een rij in AFDELING bestaan met de primaire 
sleutelwaarde ‘Financiën’ als we Afdelingnaam in WERKNEMER veranderen van 
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‘Boekhouding’ in ‘Financiën’. De wijziging moet geweigerd worden als dat niet het 
geval is. 

Als de parent-rij vereist is, zijn er geen beperkingen wat betreft het verwijderen 
van child-rijen. Een child kan verdwijnen zonder dat dit consequenties heeft voor de 
parent. 


Opmerking 

De acties die moeten worden uitgevoerd voor het bijwerken, zijn anders voor de parent dan voor de 
child als de parent een surrogaatsleutel heeft. Waar het de parent betreft, zal de surrogaatsleutel nooit 
veranderen, wat betekent dat bijwerkacties kunnen worden genegeerd. Waar het de child betreft, kan 
de externe sleutel echter veranderen als de child een andere parent krijgt. Dat betekent dat je de acties 
aan de kant van de parent kunt negeren als de sleutel een surrogaat is. Je zult aan de kant van de child 
echter wel rekening moeten houden met bijwerkacties, ook al is de sleutel van de parent een surrogaat. 


6.9.4 Acties als de child vereist is 

Als de child vereist is, moeten we zeker stellen dat elke parent altijd minstens één 
child-rij heeft. De laatste child kan de parent niet verlaten. De laatste WERKNEMER 
kan de AFDELING bijvoorbeeld niet verlaten als een AFDELING een WERKNEMER 
vereist in de relatie AFDELING/WERKNEMER. Zoals je in Figuur 6-23(b) ziet, heeft 
dat ook gevolgen voor de acties op de child. 

Het handhaven van vereiste children is veel moeilijker dan het handhaven van 
vereiste parents. We moeten alleen controleren of er een overeenkomst bestaat tus- 
sen de primaire en externe sleutelwaarden om een vereiste parent te handhaven. We 
moeten tellen hoeveel children een parent heeft om een vereiste child te handhaven. 
Dat verschil betekent dat we code moeten schrijven voor het handhaven van vereiste 
children. Laten we om te beginnen eens kijken welke acties er nodig zijn voor een 
vereiste child, vanuit het gezichtspunt van de parent. 


6.9.5 Acties op de parent-rij als de child vereist is 

Als de child vereist is, kunnen we geen nieuwe parent maken zonder ook een relatie 
naar een child te maken. Dat betekent dat we een bestaande child-rij moeten vinden 
en dat we de externe sleutel daarvan moeten veranderen, zodat deze overeenkomt 
met de sleutel van de nieuwe parent, of dat we tegelijk met de nieuwe parent ook een 
nieuwe child-rij moeten maken. Het invoegen van de parent moet worden geweigerd 
als geen van deze beide acties mogelijk is. Deze regels zijn samengevat in de eerste 
rij van Figuur 6-23(b). 

Als de primaire sleutel van de parent gewijzigd moet worden en de child vereist 
is, moet de sleutel van minstens één child ook gewijzigd worden, of de bijwerking 
moet geweigerd worden. Deze beperking is nooit van toepassing op parents met sur- 
rogaatsleutels, want de waarden daarvan veranderen nooit. 

Er hoeft ten slotte geen actie te worden ondernomen als de parent wordt verwij- 
derd en de child vereist is. Het is de child die vereist is en niet de parent — de parent 
kan daarom verdwijnen zonder dat dit verdere consequenties heeft. 
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6.9.6 Acties op de child-rij als de child vereist is 
Zoals je in Figuur 6-23(b) ziet, hoef je, als de child vereist is, geen speciale actie te 
ondernemen bij het invoegen van een nieuwe child. Dit heeft geen invloed op welke 
parent dan ook. Er zijn echter wel beperkingen op het bijwerken van de externe sleu- 
tel van een vereiste child. Om specifiek te zijn: de bijwerking kan niet worden uit- 
gevoerd als de child de laatste child van zijn huidige parent is. Zou dat toch worden 
gedaan, dan zou de parent kinderloos worden en dat is niet toegestaan. Dat betekent 
dat we een procedure moeten schrijven die bepaalt hoeveel children de huidige pa- 
rent heeft. Zijn dat er twee of meer, dan kan de externe sleutelwaarde van de child 
gewijzigd worden. Is dat niet het geval, dan wordt de bewerking verboden. 

Er is een soortgelijke beperking die het verwijderen van vereiste children be- 
treft. Is de child de laatste child van de parent, dan wordt de verwijdering niet toe- 


gestaan. Is dat niet het geval, dan kan de child zonder verdere beperkingen worden 
verwijderd. 


6.9.7 Acties implementeren voor M-O-relaties 

Figuur 6-25 geeft een overzicht van de acties uit Figuur 6-23 voor elk soort mini- 
mumkardinaliteit. Zoals al eerder vermeld, hoeven we geen rekening te houden met 
O-O-relaties want deze leggen geen beperkingen op. 


Minimum Toe te passen actie Opmerkingen 
kardinaliteit 


van relatie 


Acties voor vereiste Kan gemakkelijk worden 

parent (Figuur 6-23(a)). gehandhaafd door het DBMS — 
definieer een referential integrity- 
constraint en maak de externe 
sleutel NOT NULL. 


Acties voor vereiste Moeilijk te handhaven. Vereist 
child (Figuur 6-23(b)). gebruik van triggers of andere 
toepassingscode. 


Acties voor vereiste parent Heel moeilijk te handhaven. 

en acties voor vereiste Vereist een combinatie van 

child (Figuur 6-23(a) en (b)). ingewikkelde triggers. Triggers 
kunnen zich elkaar lamleggen. 
Veel problemen! 


Figuur 6-25 Acties die moeten worden toegepast voor het afdwingen van de minimumkardinaliteit 


M-O-relaties vereisen dat de acties uit Figuur 6-23(a) worden uitgevoerd. We moeten 
zeker stellen dat elke child een parent heeft en dat bewerkingen op parent- of child- 
rijen nooit tot weeskinderen leiden. 
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Deze acties zijn gelukkig makkelijk uit te voeren met behulp van voorzieningen die 
in de meeste DBMS-producten beschikbaar zijn. Het blijkt dat we deze acties kun- 
nen uitvoeren door maar twee beperkingen op te leggen. We moeten om te beginnen 
een referentiële integriteitsvoorwaarde definiëren, die ervoor zorgt dat elke externe 
sleutelwaarde overeenkomt met een bestaande waarde in de parent-tabel. We moe- 
ten de externe sleutelkolom verder NOT NULL maken. Deze twee beperkingen lei- 
den ertoe dat alle acties uit Figuur 6G-23(a) worden uitgevoerd. 

Neem het voorbeeld met AFDELING en WERKNEMER. Als we de volgende re- 
ferentiële integriteitsvoorwaarde definiëren, weten we dat elke waarde van Afdeling- 
naam in WERKNEMER overeen zal komen met een waarde in AFDELING: 


Afdelingnaam in WERKNEMER moet bestaan in 
Afdelingnaam in AFDELING 


We weten bovendien dat elke rij in WERKNEMER een geldige AFDELING zal heb- 
ben als we Afdelingnaam vereist maken. 

Vrijwel elk DBMS-product heeft voorzieningen voor het definiëren van referen- 
tiële integriteitsvoorwaarden. Je ziet in het volgende hoofdstuk hoe je daar SQL- 
statements voor schrijft. In die statements heb je de mogelijkheid op te geven of er 
cascading update of deletion moet worden uitgevoerd, of dat het moet worden ver- 
boden. Als je eenmaal de juiste voorwaarde hebt gedefinieerd en de externe sleutel 
NOT NULL hebt gemaakt, draagt het DBMS zorg voor het uitvoeren van alle acties 
uit Figuur 6-23(a). 


Opmerking 

Denk eraan dat het niet vitmaakt van welke van de beide tabellen de sleutel in de andere tabel 

wordt geplaatst in een 1:1 sterke entiteitenrelatie. Het is over het algemeen het beste de sleutel in de 
optionele tabel te plaatsen als de minimumkardinaliteit van de relatie M-O of O-M is. Deze plaatsing zal 
de parent vereist maken, wat makkelijker te handhaven is. Het enige wat je moet doen, is de referential 
integrity constraint definieren en de externe sleutel NOT NULL maken voor een vereiste parent. Maar 

als je de externe sleutel zo plaatst dat de child vereist is, geeft dat handen vol werk. Zie de volgende 
paragraaf. 


6.9.8 Acties implementeren voor O-M-relaties 

Als de child vereist is, levert het DBMS helaas niet veel hulp. Er is geen eenvoudig 
mechanisme dat zeker kan stellen dat er toepasselijke externe sleutelwaarden in de 
child bestaan. Er is ook geen andere eenvoudige manier om zeker te stellen dat gel- 
dige relaties geldig blijven als er rijen worden ingevoegd, bijgewerkt of verwijderd. 
Je zult daar zelf voor moeten zorgen. 

Voorwaarden voor vereiste children worden meestal gehandhaafd met behulp 
van triggers. Triggers zijn codemodules die door het DBMS worden aangeroepen als 
er specifieke gebeurtenissen optreden. Vrijwel alle DBMS-producten kennen trig- 
gers voor bewerkingen voor het invoegen, bijwerken en verwijderen. Een trigger de- 
finieer je voor een actie op een bepaalde tabel. Je kunt dus een trigger maken voor 
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invoegen in klant, of een trigger voor bijwerken van werknemer, enzovoort. Je leest 
meer over triggers in hoofdstuk 7. 

Kijk nog eens naar Figuur 6-23(b) om te zien hoe je triggers gebruikt voor het 
handhaven van vereiste children. We zullen aan de kant van de parent een trigger 
moeten schrijven voor het invoegen in en voor het bijwerken van de parent-rij. Der- 
gelijke triggers kunnen de vereiste child maken, of een bestaande child van een an- 
dere parent stelen. Zijn ze niet in staat een van deze acties uit te voeren, dan moeten 
ze de invoeging of bijwerking annuleren. 

Het invoegen van een child levert geen problemen op aan de kant van de child. 
Heeft een child eenmaal een parent gekregen, dan kan deze de parent echter niet 
verlaten als de child de laatste of de enige child is. Dat betekent dat we triggers voor 
het bijwerken en verwijderen moeten schrijven voor de child die de volgende logica 
hebben: is de externe sleutelwaarde null, dan heeft de child geen parent en de bijwer- 
king of verwijdering kan worden uitgevoerd. Heeft de externe sleutel echter wel een 

waarde, dan moet worden gecontroleerd of de rij de laatste child is. Is dat het geval, 
dan moet de trigger de parent verwijderen en een vervangende child zoeken, of de 
bijwerking of verwijdering verbieden. 

Het DBMS zal geen van deze acties automatisch uitvoeren. Je moet deze regels 
in plaats daarvan afdwingen door daar code voor te schrijven. Je vindt in het volgen- 
de hoofdstuk algemene voorbeelden van dergelijke code en je vindt in hoofdstuk 1o 
echte voorbeelden voor SQL Server. 


6.9.9 Acties implementeren voor M-M-relaties 

M-M-relaties zijn heel moeilijk te handhaven. De acties uit Figuur 6-23(a) en (b) 
moeten allemaal tegelijk worden toegepast. We hebben een behoeftige parent en een 
behoeftige child, en ze willen geen van beide de ander loslaten. 

Neem bijvoorbeeld het invoegen van nieuwe rijen in AFDELING en WERK- 
NEMER als deze tabellen een M-M-relatie hebben. We zullen aan de kant van AF- 
DELING een trigger moeten schrijven die zal proberen een nieuwe WERKNEMER 
in te voegen voor de nieuwe AFDELING. De tabel WERKNEMER zal echter een 
eigen insert-trigger hebben, die zal worden aangeroepen als er wordt geprobeerd 
deze nieuwe WERKNEMER in te voegen. Deze trigger zal voorkomen dat de WERK- 
NEMER wordt ingevoegd, tenzij deze een AFDELING-rij heeft. De nieuwe AFDE- 
LING-rij bestaat echter nog niet, want het DBMS is aan het proberen een nieuwe 
WERKNEMER-rij te maken, die nog niet bestaat omdat de nieuwe AFDELING-rij 
nog niet bestaat, die nog niet bestaat omdat de nieuwe WERKNEMER-rij nog niet 
bestaat, enzovoort. 

Denk nu eens na over het verwijderen bij dezelfde M-M-relatie. Stel dat we een 
AFDELING willen verwijderen. We kunnen geen afdeling verwijderen die WERK- 
NEMER-children heeft. We moeten alle werknemers in deze afdeling dus eerst aan 
een andere afdeling toekennen (of ze verwijderen), voordat we de AFDELING ver- 
wijderen. Er zal echter een update-trigger voor WERKNEMER worden aangeroepen 
als we proberen de laatste WERKNEMER opnieuw toe te kennen (of te verwijderen). 
Deze trigger staat niet toe dat de laatste werknemer opnieuw wordt toegekend (want 
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de trigger is geprogrammeerd om zeker te stellen dat elke AFDELING minstens één 
WERKNEMER heeft). Het probleem is nu: de laatste werknemer kan de afdeling 
niet verlaten en de afdeling kan pas worden verwijderd als alle werknemers vertrok- 
ken zijn. 

Dat probleem is op diverse manieren op te lossen, maar geen van deze manieren 
is echt tevredenstellend. We laten in het volgende hoofdstuk een mogelijke oplossing 
zien die met SQL Views werkt. Deze oplossing is ingewikkeld en vereist exact ge- 
schreven programma's die moeilijk te maken zijn. Het beste advies dat we je kunnen 
geven, is om M-M-relaties waar mogelijk te vermijden. Als dat niet mogelijk blijkt, 
houd er dan rekening mee dat deze relaties veel tijd kosten. 


6.9.10 M-M-relaties voor speciale gevallen ontwerpen 

Niet alle M-M-relaties zijn zo erg als de vorige paragraaf doet vermoeden. M-M-rela- 
ties tussen sterke entiteiten zijn weliswaar over het algemeen echt zo ingewikkeld, 
maar M-M-relaties tussen sterke en zwakke entiteiten zijn vaak makkelijker. Neem 
bijvoorbeeld de relatie tussen BEDRIJF en TELEFOON _ CONTACT uit Figuur 6-24. 
TELEFOON CONTACT is ID-afhankelijk en moet daarom een BEDRIJF-parent 
hebben. Neem bovendien aan dat de toepassingseisen aangeven dat elke BEDRIJF- 
rij minstens één rij moet hebben in TELEFOON_CONTACT. Dat betekent dat de 
relatie M-M is. 

Transacties worden echter vrijwel altijd gestart vanaf de kant van de sterke en- 
titeit. Een data-invoerformulier zal met een BEDRIJF beginnen en de gegevens uit 
de tabel TELEFOON_CONTACT zullen dan ergens in het hoofddeel van het formu- 
lier te vinden zijn. Dat betekent dat alle activiteiten voor het invoegen in, bijwerken 
van en verwijderen uit TELEFOON-_CONTACT het resultaat zullen zijn van de een 
of andere actie op het BEDRIJF. Deze situatie betekent dat we de kolommen ‘Actie 
op child’ uit Figuur 6-23(a) en (b) kunnen negeren — niemand zal ooit proberen een 
nieuw TELEFOON CONTACT in te voegen, bij te werken of te verwijderen, ten- 
zij dat in de context van het invoegen, wijzigen of verwijderen van een BEDRIJF 
gebeurt. 

We moeten echter alle acties uit de kolommen ‘Actie op parent’ uit Figuur 
6-23(a) en (b) toepassen omdat de relatie M-M is. We moeten altijd een child ma- 
ken als er een rij in de parent wordt ingevoegd. We kunnen aan deze eis voldoen 
door een trigger voor invoegen in BEDRIJF te schrijven die automatisch een nieu- 
we rij in TELEFOON _CONTACT maakt met nullwaarden voor Contactpersoon en 
Telefoonnummer. 

Wat betreft bijwerken en verwijderen: we moeten alle resterende acties uit Figuur 
6-23(a) en (b) alleen cascading uitvoeren. Wijzigingen in BEDRIJF.Bedrijfsnaam 
zullen doorgegeven worden aan TELEFOON_CONTACT.Bedrijfsnaam. De TELE- 
FOON_CONTACT-rijen van een BEDRIJF zullen automatisch verwijderd worden 
als dat bedrijf wordt verwijderd. Dat is ook logisch — we zullen vast en zeker geen ge- 
gevens over contactpersonen en telefoonnummers van een bedrijf nodig hebben als 
we geen gegevens meer willen hebben over dat bedrijf. 
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Opmerking 

Het handhaven van M-M-relaties is zo moeilijk dat ontwikkelaars naar speciale omstandigheden zoeken 
om de zaak te vereenvoudigen. Zoals je al zag, bestaan er dergelijke omstandigheden voor relaties 
tussen sterke en zwakke entiteiten. Tussen sterke entiteiten bestaan dergelijke speciale omstandigheden 
mogelijk niet. De M-M-kardinaliteit wordt in dat geval soms domweg genegeerd. Dat kunnen we 
natuurlijk niet doen voor applicaties zoals financieel beheer of bewerkingen die een nauwgezet 
gegevensbeheer vereise. Het kan echter beter zijn de relatie te herdefinieren als M-O voor een 


toepassing zoals vliegticketreserveringen, waar toch meer zitplaatsen worden geboekt dan er werkelijk 
beschikbaar zijn. 


6.10 De minimumkardinaliteit documenteren in het ontwerp 


Het handhaven van de minimumkardinaliteit kan ingewikkeld zijn en omvat vaak 
het maken van triggers of andere procedures. Een duidelijke documentatie is daar- 
om van groot belang. Het ontwerp voor het handhaven van vereiste parents is een- 
voudiger dan dat voor het handhaven van vereiste children. We gebruiken daarom 
verschillende technieken voor het documenteren van elk van deze ontwerpen. 


6.10.1 Vereiste parents documenteren 

Tools zoals ERwin, Visio en MySQL WorkBench maken het je mogelijk referential 
integrity(RI)-acties te definiëren voor elke tabel. Deze definities zijn nuttig voor het 
documenteren van de acties die nodig zijn voor vereiste parents. Er zijn volgens 
Figuur 6-23(a) drie ontwerpbeslissingen nodig voor vereiste parents: (1) bepalen of 
het bijwerken van de primaire sleutel van de parent cascading moet worden uitge- 
voerd, of moet worden verboden, (2) bepalen of het verwijderen van de parent cas- 
cading moet worden uitgevoerd, of moet worden verboden, (3) aangeven hoe een 
parent-rij wordt geselecteerd als een child wordt ingevoegd. 


BEDRIJF 


Plaats 
Land 


Volume 


ni 


AFDELING 


Q\ Afdelingnaam 2 


Budgetcode 
Postbus 
Bedrijfsnaam (FK) 


Figuur 6-26 Voorbeelden van Rl-acties voor een M-O-relatie 
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Figuur 6-26 laat de documentatie zien van een relatie met een vereiste parent tussen 
BEDRIJF en AFDELING. De notatie U:C (Update:Cascade) betekent dat het bijwer- 
ken van de sleutel van BEDRIJF cascading moeten worden doorgegeven aan AFDE- 
LING. D:R (Delete:Restricted) geeft aan dat er beperkingen worden opgelegd aan het 
verwijderen uit BEDRIJF — dat wil zeggen dat een verwijdering wordt verboden als 
BEDRIJF een of meer AFDELING-rijen heeft. De notatie I:SD (Insert:Set Default) 
naast AFDELING betekent ten slotte dat een standaardbeleid moet worden gebruikt 
voor het vinden van een BEDRIJF als een AFDELING wordt ingevoegd. Dat beleid 
zal ergens anders in de ontwerpdocumentatie worden gedocumenteerd. Notaties zo- 
als U:C noemen we referential integrity-acties of kortweg Rl-acties. 


Opmerking 

Referential integrity-acties kunnen we in theorie niet alleen gebruiken voor het documenteren van 
benodigde acties voor het handhaven van vereiste parents, maar ook voor het documenteren van 

de acties voor vereiste children. Het wordt echter verwarrend en dubbelzinnig als we ze voor beide 
doeleinden gebruiken. Een child in een M-M-relatie kan bijvoorbeeld een verzameling regels voor het 
invoegen hebben omdat de parent vereist is - en een andere verzameling regels voor het invoegen 
omdat de child vereist is. De referential integrity-acties voor het invoegen zullen dan veranderen, 
afhankelijk van voor welk van de beide doeleinden deze worden gebruikt, en de betekenis ervan zal in 
het beste geval dubbelzinnig zijn. We gebruiken de referential integrity-acties daarom in dit boek alleen 
voor het documenteren van vereiste parents. We gebruiken een andere techniek voor het documenteren 
van vereiste children. We zullen deze techniek als volgende bespreken. 


6.10.2 Vereiste children documenteren 

De acties die nodig zijn voor het handhaven van een vereiste child kunnen we mak- 
kelijk en ondubbelzinnig definiëren door Figuur 6-23(b) als een documentsjabloon 
te gebruiken. Maak een kopie van deze figuur voor elke relatie die een vereiste child 
heeft en vul de specifieke acties in voor invoeg-, bijwerk- en verwijderbewerkingen. 


Neem bijvoorbeeld Figuur 6-27, die een O-M-relatie weergeeft tussen HUIS en 
INSPECTIE. Een gegeven huis moet minstens één inspectie hebben, maar een 
inspectie hoeft niet aan welk huis dan ook te zijn gerelateerd. HUIS heeft een sur- 
rogaatsleutel, HuisSK, en andere kolommen, zie Figuur 6-27. 

We passen de tabel uit Figuur 6-23(b) toe omdat de relatie HUIS/INSPECTIE 
een vereiste child heeft. Je ziet het resultaat in Figuur 6-28. Er worden hier triggers 
beschreven voor het invoegen in HUIS en het verwijderen uit INSPECTIE. Er zijn 
geen bijwerkacties nodig voor HUIS, omdat HUIS een surrogaatsleutel heeft, en het 
bijwerken van INSPECTIE is verboden, vanwege de surrogaatsleutel en ook omdat 
inspecties nooit opnieuw (aan een ander huis) worden toegekend. 
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HUIS 


Straat 


Plaats 


Provincie_Staat 
Postcode _Zipcode 


Land 


0; 
Ï 
Ü 
| 
l 
! 


VN 
INSPECTIE 


Datum 
Inspecteur 
Bedrijf 


HuisSK (FK) 


AN Inspectienummer 


Bestandsnummer 


Figuur 6-27 Een O-M-relatie tussen HUIS en INSPECTIE 


INSPECTIE 
is vereist 


Invoegen 


Sleutel of 
externe 
sleutel 
wijzigen 


Verwijderen 


Actie op HUIS Actie op INSPECTIE 


Trigger voor het maken van 
een rij in INSPECTIE als er 

in HUIS wordt ingevoegd. 
Verbied het invoegen in HUIS 
als er geen INSPECTIE- 
gegevens beschikbaar zijn. 


Onmogelijk — surrogate Verbied. HUIS heeft een 
key. surrogate key en inspecties 
veranderen nooit van huis. 


Trigger voor het verbieden als 
dit de enige rij in INSPECTIE is. 


Figuur 6-28 Acties voor het handhaven van de O-M-relatie tussen HUIS en INSPECTIE 


6.11 Nog een complicatie 


Wees je ervan bewust dat er nog een complicatie bestaat die buiten het bereik van 
dit boek valt. Een tabel kan aan veel verschillende relaties deelnemen. Er kunnen 
in feite meer relaties bestaan tussen dezelfde twee tabellen. Je moet een ontwerp 
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opgeven voor de minimumkardinaliteit van elke relatie. De minimumkardinaliteit 
zal voor elke relatie anders zijn. Deze zal soms O-M zijn, soms M-O en soms M-M. 
Sommige relaties zullen triggers vereisen, wat betekent dat je meerdere reeksen trig- 
gers voor invoegen, bijwerken en verwijderen kunt hebben per tabel. Het is niet al- 
leen moeilijk een dergelijke verzameling triggers te schrijven en te testen, de acties 
van de verschillende triggers kunnen bovendien met elkaar in botsing komen als ze 
worden uitgevoerd. 

Je hebt meer kennis en ervaring nodig voor het ontwerpen, implementeren en 
testen van dergelijke ingewikkelde verzamelingen triggercode en DBMS-voorwaar- 
den. Je moet je er op dit moment alleen van bewust zijn dat deze problemen bestaan. 


6.11.1 Samenvatting van het ontwerpen van de minimumkardinaliteit 
Figuur 6-29 vat samen hoe de minimumkardinaliteit van relaties wordt ontworpen. 
Deze figuur toont elk type relatie, de ontwerpbeslissingen die daarvoor moeten wor- 
den genomen en de documentatie die daarvoor moet worden gemaakt. Gebruik deze 
figuur als leidraad. 


Minimum- |Ontwerpbeslissingen die moeten 
kardinaliteit [worden genomen 
van relatie 


Ontwerpdocumentatie 


M-O e Bijwerken: cascading of verbieden? 
e Verwijderen: cascading of verbieden? 
e Beleid voor het verkrijgen van een 
parent als er een child wordt 


ingevoegd. 


Referential integrity-acties (Rl-acties), 
plus documentatie voor het beleid 
voor het verkrijgen van de parent als 
er een child wordt ingevoegd. 


e Beleid voor het verkrijgen van een [Gebruik Figuur 6-23 (b) als sjabloon. 
child als er een parent wordt 
ingevoegd. 

* Bijwerken primaire sleutel: 
cascading of verbieden? 

e Beleid voor het bijwerken van de 
externe sleutel van de child. 
„Beleid voor het verwijderen van 
een child. 


Alle voornoemde beslissingen voor 
M-O en O-M, plus hoe conflicten 
tussen triggers moeten worden 
verwerkt als de eerste instantie van 
een parent/child wordt 

ingevoegd en de laatste parent/ 
child-instantie wordt verwijderd. 


Voor verplichte parent: Rl-acties plus 
documentatie voor het beleid voor het 
verkrijgen van een parent als een child | 
wordt ingevoegd. Voor verplichte child: |} 
gebruik Figuur 6-23(b) als sjabloon. 
Voeg documentatie toe over hoe 
conflicten tussen triggers moeten 
worden verwerkt. 


Figuur 6-29 Samenvatting van het ontwerpen van de minimumkardinaliteit 
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6.12 De database voor galerie View Ridge 


We sluiten dit hoofdstuk af met een voorbeeld van een ontwerpprobleem. Neem de 
tijd om dit ontwerp goed te begrijpen, want we gebruiken het in de rest van dit boek 
telkens opnieuw. We kozen dit specifieke probleem omdat het gebruikelijke relaties 
omvat en redelijk ingewikkeld is. Er zijn voldoende uitdagingen om het interessant 
te maken, maar niet zo veel dat het al te moeilijk wordt. 


6.12.1 Een samenvatting van de eisen 
View Ridge Gallery (of VRG) is een kleine kunstgalerie die hedendaagse Europese en 
Noord-Amerikaanse kunstwerken verkoopt, waaronder lithografieën, originele schil- 
derijen en foto’s. Alle lithografieën en foto's zijn ondertekend en genummerd en de 
meeste kunstwerken hebben een prijs tussen € sooo en € 5o.ooo. View Ridge bestaat 
al dertig jaar en heeft een fulltime eigenaar, drie verkopers en twee werknemers die 
lijsten maken, kunstwerken ophangen in de galerie en kunstwerken klaarmaken 
voor verzending. View Ridge organiseert openingen en andere galerie-evenementen 
om klanten naar de galerie te lokken. Er worden ook kunstwerken tentoongesteld bij 
plaatselijke bedrijven en restaurants en op andere publieke plaatsen. View Ridge is 
de eigenaar van alle kunstwerken die de galerie verkoopt — er worden geen kunstwer- 
ken verkocht in consignatie. 

Een overzicht van de eisen voor de applicatie voor View Ridge zie je in Figuur 
6-30. De eigenaar en de verkopers willen om te beginnen de namen, adressen, te- 
lefoonnummers en e-mailadressen van de klanten bijhouden. Ze willen ook weten 
welke klanten in welke kunstenaars zijn geïnteresseerd. De verkopers gebruiken 
deze informatie om te bepalen met wie ze contact moeten opnemen als er nieuwe 


kunstwerken aankomen en om de communicatie met hun klanten persoonlijker te 
maken. 


Houd de klanten bij en houd bij in welke kunstenaars deze geïnteresseerd zijn. | 
Registreer de aankopen van de galerie. | 
Registreer welke klanten welke kunstwerken hebben gekocht. 

Houd een lijst bij met de kunstenaars en de kunstwerken die in de galerie zijn tentoongesteld. 
Rapporteer hoe snel en met welke winstmarge de kunstwerken van een kunstenaar verkopen. 
* Geef de huidige inventaris weer op een webpagina. 


Figuur 6-30 Een samenvatting van de eisen van View Ridge 


Wanneer de galerie nieuwe kunstwerken koopt, worden gegevens opgeslagen over 
de kunstenaar, de aard van het kunstwerk, de aankoopdatum en de aanschafprijs. De 
galerie koopt soms ook kunstwerken terug van een klant en verkoopt deze opnieuw. 
Hetzelfde kunstwerk kan dus meerdere malen in de galerie verschijnen. De kun- 
stenaar en de gegevens over het kunstwerk worden niet opnieuw ingevoerd als een 
kunstwerk wordt teruggekocht. De meest recente aanschafdatum en aanschafprijs 
worden echter wel geregistreerd. De verkoopdatum, de verkoopprijs en de identi- 
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teit van de klant worden bovendien in de database opgenomen als er een kunstwerk 
wordt verkocht. 

De verkopers willen oude verkoopgegevens analyseren, zodat ze meer tijd kun- 
nen besteden aan de klanten die het meest kopen. Ze gebruiken de verkoopgegevens 
soms ook om te bepalen waar kunstwerken zich bevinden die ze in het verleden heb- 
ben verkocht. 

View Ridge wil om marketingredenen dat hun databasetoepassing een lijst kan 
leveren van kunstenaars en kunstwerken die in de galerie zijn tentoongesteld. De ei- 
genaar zou ook graag in staat zijn te bepalen hoe snel het werk van een kunstenaar 
verkoopt en wat de winstmarge daarvan is. De databasetoepassing moet bovendien 
de huidige inventaris kunnen weergeven in een webpagina die de klanten via het in- 
ternet kunnen bekijken. 


6.12.2 Het datamodel voor View Ridge 

Figuur 6-31 toont een datamodel voor de database van View Ridge. Dit model heeft 
twee sterke entiteiten: CUSTOMER en ARTIST. De entiteit WORK is verder [D-af- 
hankelijk van ARTIST en de entiteit TRANS is ID-afhankelijk van WORK. Er is ook 
een niet-identificerende relatie van CUSTOMER naar WORK. 


CUSTOMER 


ARTIST 


KOOPT/ _ TRANS WORK MAAKT/__ ron 
Ee VERKOCHT (pateAcquired | VERWORVEN (titie GOED 
FirstName Copy FirstName 
AreaCode q AcquisitionPrice Pp 


Nationality 
DateOfBirth 
DateDeceased 


-o- : 
LocalNumber DateSold Medium 
Street SalesPrice Description 
City AskingPrice 

State 


ZipPostalCode 
Country 
y 


IS GEÏNTERESSEERD IN/WORDT BEWONDERD DOOR 


Figuur 6-31 Het datamodel voor View Ridge 


Merk op dat we de naam TRANS hebben gebruikt in plaats van TRANSACTION. 
Dit doen we omdat transaction een gereserveerd woord is in de meeste (zo niet alle) 
DBMS-producten. Als je gereserveerde woorden als table of column gebruikt, kan dat 
tot problemen leiden. In hoofdstuk ro lees je hier meer over. 

In de VRG-database kunnen kunstenaars worden geregistreerd van wie nog geen 
kunstwerken in de galerie zijn verschenen. Dat wordt gedaan om voorkeuren van 
klanten te registreren voor kunstenaars van wie misschien in de toekomst kunstwer- 
ken worden aangeschaft. Dat betekent dat een kunstenaar nul tot veel werken kan 
hebben. 

De identifier van WORK is de samenstelling (Title, Copy) omdat er in het geval 
van lithografieën en foto's veel kopieën kunnen zijn van een gegeven titel. De eisen 
geven ook aan dat een kunstwerk meerdere malen in de galerie kan verschijnen. Er 
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kunnen dus potentieel veel TRANS-entiteiten nodig zijn voor elk WORK. De aan- 
schafdatum en -prijs moeten telkens geregistreerd worden als een kunstwerk in de 
galerie wordt opgenomen. Dat betekent dat elk WORK minstens een TRANS-rij 
moet hebben. 

Een klant kan veel kunstwerken kopen — dat wordt geregistreerd in de r:N-relatie 
van CUSTOMER naar TRANS. Merk op dat deze relatie in beide richtingen optio- 
neel is. Er is ten slotte een N:M-relatie tussen CUSTOMER en ARTIST. Dat is een 
N:M sterke entiteitenrelatie — het team heeft vruchteloos naar een ontbrekend attri- 
buut gezocht dat een associatierelatie zou aangeven. 


6.13 Het eerste databaseontwerp 


Figuur 6-32 toont een eerste databaseontwerp voor het datamodel uit Figuur 6-31. 
Dit ontwerp maakt gebruik van sleutels die op gegevens gebaseerd zijn, en elke pri- 
maire sleutel heeft problemen, behalve de samenstelling (ARTIST.LastName, AR- 
TIST.FirstName). De sleutels voor WORK en TRANS zijn enorm groot en de sleutel 
voor CUSTOMER is bedenkelijk — een aantal klanten zal misschien geen e-mailadres 
hebben. Het ontwerp roept vanwege deze problemen letterlijk om surrogaatsleutels. 


CUSTOMER 
EN sen | Een AK ARTIST 
rr [& Lasthame (FI) Q Lastname (FR) MAT A 
| _ LastName [AAN S FirstName (FK)_ | vERWORVEN | 9 FirstName (FK) 55 S\ LastName 
|__ FirstName | S\ pateAcquired BOOR FirstName | 
AreaCode po--0 Or 
LocalNumber | | Nationality | 
| DateOfBirth | 
Ee | Acts tonErice | DateDeceased | 
DateSold : 
SE | SalesPrice En 
ZipPostaiCode | AskingPrice | 
Country Email (FK) 


| CUSTOMER_ARTIST_INT 
SV LastName (FK) 


AN FirstName (FK) 
Email (FK) 


IS GEÏNTERESSEERD IN WORDT BEWONDERD DOOR 


Figuur 6-32 Het eerste ontwerp van de VRG-database 


6.13.1 Een databaseontwerp met surrogaatsleutels 
Je ziet de versie van het databaseontwerp met surrogaatsleutels voor de VRG-data- | 
base in Figuur 6-33. Merk op dat de twee identificerende relaties (TRANS - WORK) 
en (WORK - ARTIST) gewijzigd zijn in niet-identificerende relaties. Dit is gedaan | 
omdat zodra ARTIST een surrogaatsleutel heeft er geen reden meer is ID-afhanke- ; 
lijke sleutels in WORK en TRANS op te slaan. Let erop dat WORK en TRANS beide Î 
zwakke entiteiten zijn, ook al zijn ze niet meer ID-afhankelijk. | 

Merk op dat (ARTIST.LastName, ARTIST. FirstName) is gedefinieerd als een al- | 
ternatieve sleutel. Daardoor wordt gegarandeerd dat kunstenaars niet In de database : 
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worden gedupliceerd. (Title, Copy) wordt in WORK ook als een alternatieve sleutel 
gedefinieerd, zodat een gegeven kunstwerk niet meer dan eens kan voorkomen. 

De plaatsing van de externe sleutels wordt rechtstreeks bepaald door de technie- 
ken toe te passen die we in dit hoofdstuk beschreven. Bedenk dat TRANS.Customer- 
ID nullwaarden mag hebben — dat maakt het mogelijk dat er een TRANS-rij wordt 
gemaakt voordat het kunstwerk door een klant is gekocht. Alle andere externe sleu- 
tels zijn vereist. 


CUSTOMER 
mcd 
[\customerip | ARTIST 
lensen | KOOPT/ STRANS WORK MAAKT/ & 
LastName e ArtistID 
| : m VERKOCHT \ TransactioniD VERWORVEN EN WorklD GEMAAKT ist 
| FirstName AAN | DOOR EN AKAH 
|_ AreaCode manen de DateAcquired  Pt----+ Title (AK1.1) POTT ih Pr 
{_LocalNumber AcquisitionPrice | Copy (AK1.2) B ks iS i 
Street DateSold [ Medium Nationality 
| City | | SalesPrice | Description DateOfBirth 
State | AskingPrice | ArtistID (FK) DateDeceased 
: Í WorkID (FK) | si 
| ZipPostalCode CustomerD (FK) | =d 
{_Country 
|___Email (AK1.1) 


7 CUSTOMER _ARTIST_INT | 


| S CustomeriD (FK) 
od SArtistiD (FK) 


DO 
IS GEÏNTERESSEERD IN WORDT BEWONDERD DOOR 


Figuur 6-33 Het uiteindelijke ontwerp van de VRG-database 


6.14 De minimumkardinaliteit handhaven voor verplichte 
parents 


We moeten volgens Figuur 6-23(a) voor elke relatie waarbij een vereiste parent be- 

trokken is, het volgende beslissen: 

of we het bijwerken van de primaire sleutel van de parent cascading doorgeven of 
verbieden; 

* of we het verwijderen van een parent cascading doorgeven of verbieden; 

* hoe we een parent verkrijgen als er een nieuwe child wordt gemaakt. 


Omdat er geen consistente manier is om deze acties te documenteren in commer- 
ciële databaseontwerp-programma's gebruiken we de sjablonen uit Figuur 6-23 om 
onze beslissingen te documenteren. 


Figuur 6-34 geeft een overzicht van de relaties in het ontwerp van de VRG-database. 
Omdat alle tabellen surrogaatsleutels hebben, is het niet nodig het bijwerkgedrag 
voor welke parent dan ook cascading door te geven. Sommige bijwerkacties op child- 
tabellen hebben beperkingen. Als bijvoorbeeld een WORK (child) aan een ARTIST 
(parent) is gekoppeld, hoeft het nooit een andere parent te krijgen. 
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Work 


CUSTOMER | CUSTOMER_ARTIST_INT 


ARTIST CUSTOMER _ARTIST_INT 


Kardinaliteit 


Niet-identificerend | 1:N 
Niet-identificerend | 1:N 
Niet-identificerend | 1:N 


Identificerend 


Identificerend 


Figuur 6-34 Overzicht van de relaties in het ontwerp van de VRG-database 


De bedrijfsleiding van View Ridge wil dat er nooit aan transacties gerelateerde gege- 
vens verwijderd mogen worden, omdat deze database wordt gebruikt voor het regis- 
treren van aan- en verkopen. Ze zullen misschien af en toe op grote schaal gegevens 
van vorige jaren verwijderen, maar ze zullen dat doen via een grootschalige gege- 
vensoverdracht en niet als onderdeel van een toepassing. 

Er mogen daarom nooit rijen uit CUSTOMER, WORK of ARTIST worden 
verwijderd die aan een TRANS-rij zijn gerelateerd. Merk echter op dat rijen van 
CUSTOMERS die nooit iets hebben gekocht en rijen van ARTISTs van wie kunst- 
werken nooit in de galerie zijn geweest, wel kunnen worden verwijderd. Mocht er 
een dergelijke CUSTOMER of ARTIST worden verwijderd, dan zullen er cascading 
ook rijen worden verwijderd uit de tussentabel CUSTOMER _ARTIST_INT. 


ARTIST Actie op ARTIST Actie op WORK 
Is vereiste parent (Parent) (child) 
Invoegen Geen Koppel aan een parent 


Sleutel of externe sleutel Niet toestaan: ARTIST gebruikt een Niet toestaan: ARTIST gebruikt 
wijzigen surrogaatsleutel een surrogaatsleutel | 
Verwijderen Niet toestaan als er een WORK Geen | 
bestaat: gegevens die bij een 
transactie horen worden nooit 
verwijderd. 

Sta toe als er geen WORK bestaat 


WORK 

Is vereiste parent 
Invoegen 

Sleutel of externe sleutel 
wijzigen 

Verwijderen 


Actie op WORK 
(Parent) 


Actie op TRANS 

(Child) 

Koppel aan een parent 
Niet toestaan: WORK gebruikt een| 
surrogaatsleutel 
Geen 


Niet toestaan: WORK gebruikt een 
surrogaatsleutel 

Niet toestaan: gegevens die bij 
een transactie horen worden nooit 
verwijderd. 


| 
' 
' 
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| CUSTOMER | Actie op CUSTOMER _ Tactie op CUSTOMER _ARTIST_INT 
Is vereiste parent | (Parent) (Child) 


| Invoegen Geen Koppel aan een parent 
| sleutel of externe sleutel Niet toestaan: CUSTOMER gebruikt een | Niet toestaan: CUSTOMER gebruikt 
den surrogaatsleutel een surrogaatsleutel 


| Verwijderen | Niet toestaan als er een TRANS Geen 
| bestaat: gegevens die bij een 
| transactie horen worden nooit 
| verwijderd. 

Sta toe als er geen TRANS bestaat 
| - verwijder de children (cascading 


D deletion) ES J 
[ARTIST ‘Actie op ARTIST Actie op CUSTOMER_ARTIST_INT 
Is vereiste parent (Parent) (Child) 
| Invoegen Geen Koppel aan een parent 
| Sleutel of externe sleutel | Niet toestaan: ARTIST gebruikt een Niet toestaan: ARTIST gebruikt 
| wijzigen surrogaatsleutel een surrogaatsleutel 


| Verwijderen Niet toestaan als er een TRANS Geen 
| bestaat: gegevens die bij een 
transactie horen worden nooit 
verwijderd. 

| Sta toe als er geen TRANS bestaat 
| - verwijder de children (cascading 
| deletion) 


Figuur 6-35 Acties om de minimumkardinaliteit af te dwingen voor vereiste parents 


Er zijn ook referentiële integriteits-acties nodig voor het verkrijgen van een parent 
voor WORK als een TRANS-record wordt gemaakt, en een parent ARTIST als een 
WORK wordt gecreëerd. Het beleid voor het instellen van een defaultwaarde zal in 
beide gevallen inhouden dat de toepassing de ID van de vereiste parent levert zodra 
het WORK of de TRANS wordt gemaakt. 

Al deze acties staan in Figuur 6-35, die is gebaseerd op het schema voor een ver- 
eiste parent uit Figuur 6-23(a). 


6.15 De mirimumkerdinokgen handhaven voor de vereiste 
chi 


Zoals je ziet in het overzicht in Figuur 6-34 is TRANS de enige vereiste child in 
het databaseontwerp. De acties voor het afdwingen van deze vereiste child zijn ge- 
documenteerd in Figuur 6-36, die is gemaakt op basis van de sjabloon uit Figuur 
6-23(b). Er zal volgens dit document een trigger INSERT WORK worden geschreven 
om de vereiste child te maken. Deze trigger zal telkens worden geactiveerd als een 
werk voor het eerst in de galerie verschijnt. Er zal op dat moment een nieuwe rij in 


TRANS worden gemaakt, waarin de waarden van DateAquired en AquisitionPrice 
kunnen worden opgeslagen. 
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TRANSACTION is | Actie op WORK 
vereist 


Invoegen Trigger voor het maken van 
een rij in TRANSACTION. De 
gegevens voor DateAcquired 
en AcquisitionPrice zullen 
ingevuld worden in 
TRANSACTION. De overige 
kolommen zullen NULL zijn. 


Actie op TRANSACTION 


Zal worden gemaakt door 
een INSERT-trigger op 
WORK. 


Sleutel of externe | Onmogelijk: surrogate key. 
sleutel wijzigen 


Niet toestaan. Een 
TRANSACTION moet altijd 
verwijzen naar het WORK 
waar de transactie 

voor is gemaakt. 


Niet toestaan. Niet toestaan. 


Figuur 6-36 Acties voor het afdwingen van de vereiste child van de relatie WORK/TRANS 


Er zullen geen wijzigingen optreden in de primaire sleutel van WORK, want deze 
heeft een surrogaatsleutel. Wijzigingen in de externe sleutel in TRANS zullen niet 
worden toegestaan, want een TRANS verandert nooit van werk. De galerie heeft, 
zoals al eerder opgemerkt, het beleid dat er nooit transactie- of gerelateerde gege- 
vens worden verwijderd. Verwijderingen in WORK of TRANS worden daarom niet 
toegestaan. 


Wees er zeker van dat je dit ontwerp goed begrijpt, want we gebruiken het in de 
volgende hoofdstukken. 


Samenvatting 


Er zijn drie hoofdtaken bij het omzetten van een datamodel in een databaseontwerp: 
elke entiteit moet worden vervangen door een tabel en elk attribuut door een kolom, 
relaties en maximumkardinaliteiten moeten worden gerepresenteerd door externe 
sleutels op te nemen en minimumkardinaliteiten moeten worden gerepresenteerd 
door acties te definiëren die beperkingen opleggen aan de activiteiten die worden uit- 
gevoerd op waarden van primaire en externe sleutels. 

Elke entiteit wordt tijdens het ontwerpen vervangen door een tabel. De attributen 
van de entiteit worden de kolommen van de tabel. De identifier van de entiteit wordt 
de primaire sleutel van de tabel en kandidaatsleutels in de entiteit worden kandidaat- 
sleutels in de tabel. Een goede primaire sleutel is kort, numeriek en onveranderlijk. 
Als er geen goede primaire sleutel beschikbaar is, kan in plaats daarvan een surro- 
gaatsleutel worden gebruikt. Sommige organisaties kiezen ervoor surrogaatsleutels 
te gebruiken voor al hun tabellen. Een alternatieve sleutel is hetzelfde als een kan- 
didaatsleutel. De notatie AKn.m verwijst naar de mêe kolom van de nde alternatieve 


sleutel. 
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Er moeten vier eigenschappen worden opgegeven voor elke kolom van een tabel: 
de nullstatus, het datatype, de defaultwaarde en de data constraints. Een kolom kan 
NULL of NOT NULL zijn. Primaire sleutels zijn altijd NOT NULL. Alternatieve 
sleutels kunnen NULL zijn. De datatypen zijn afhankelijk van het gebruikte DBMS. 
Algemene datatypen zijn CHAR(n), VARCHAR(n), DATE, TIME, MONEY, INTE- 
GER en DECIMAL. Een defaultwaarde is een waarde die het DBMS levert als er een 
nieuwe rij wordt gemaakt. Dat kan een eenvoudige waarde zijn, of het resultaat van 
een functie. Soms zijn triggers nodig om waarden van ingewikkelder expressies te 
leveren. 

Data constraints zijn: domain constraints, range constraints, intrarelation 
constraints en interrelation constraints. Domain constraints geven een verzameling 
waarden op die een kolom mag hebben. Range constraints geven een bereik aan 
toegestane waarden op. Intrarelation constraints betreffen vergelijkingen tussen ko- 
lommen uit dezelfde tabel, terwijl interrelation constraints vergelijkingen betreffen 
tussen kolommen uit verschillende tabellen. Een referential integrity constraint is 
een voorbeeld van een interrelation constraint. 

Zijn de tabellen, sleutels en kolommen eenmaal gemaakt, dan moeten ze aan de 
hand van normalisatiecriteria worden gecontroleerd. De tabellen zullen meestal al 
genormaliseerd zijn, maar ze moeten toch altijd gecontroleerd worden. Het zal soms 
misschien ook nodig zijn bepaalde tabellen te denormaliseren. 

De tweede stap in het ontwerpen van een database is het maken van relaties door 
toepasselijke externe sleutels op te nemen. Bij 1:1 sterke relaties kan de sleutel van 
een van de tabellen als een externe sleutel in de andere tabel worden opgenomen. Bij 
EN sterke relaties moet de sleutel van de parent in de child worden opgenomen. Bij 
N:M sterke relaties moet er een nieuwe tabel worden gemaakt, die we een intersec- 
tietabel noemen, die de sleutels van beide tabellen bevat. Intersectietabellen bevatten 
nooit gegevens die geen sleutels zijn. 

N:M-relaties, associatierelaties, meerwaardige attributen zijn drie toepassingen 
voor 1D-afhankelijke entiteiten. Een associatierelatie verschilt van een intersectie- 
tabel omdat de ID-afhankelijke entiteit gegevens bevat die geen sleutels zijn. De 
sleutel van de parent bevindt zich bij alle ID-afhankelijke entiteiten al in de child. 
Er hoeft daarom geen externe sleutel te worden gemaakt. Een instantie-entiteit van 
het archetype/instantiepatroon verandert van een [D-afhankelijke in een zwakke en- 
titeit als er een niet [D-afhankelijke identifier aan wordt toegekend. De tabellen die 
dergelijke entiteiten representeren, moeten de sleutel van de parent als een externe 
sleutel hebben. Ze blijven echter zwakke entiteiten. Als er een surrogaatsleutel aan 
de parent van een ID-afhankelijke entiteit wordt toegevoegd, moet er ook een surro- 
gaatsleutel aan de ID-afhankelijke entiteit worden toegevoegd. Het blijft echter een 
zwakke entiteit. 

Gemengde entiteiten worden gerepresenteerd door de sleutel van de parent van 
de niet-identificerende relatie in de child op te nemen. De sleutel van de parent van 
de identificerende relatie zal al in de child staan. Subtypen worden gerepresenteerd 
door de sleutel van het supertype als een externe sleutel in elk subtype te kopiëren. 
Recursieve relaties worden op dezelfde manier gerepresenteerd als 1:1-, 1:N- en N:M- 
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relaties. Het enige verschil is dat de externe sleutel naar rijen verwijst in dezelfde ta- 
bel als waar de sleutel zelf in staat. 

Drieledige relaties worden ontleed in binaire relaties. Soms zullen we echter bi- 
naire voorwaarden moeten documenteren. MUST, MUST NOT en MUST COVER 
zijn drie van dergelijke voorwaarden. 

De derde stap in het ontwerpen van een database is het opstellen van een plan 
voor het afdwingen van de minimumkardinaliteit. Figuur 6-23 laat zien welke ac- 
ties moeten worden ondernomen voor het handhaven van de minimumkardinaliteit 
voor vereiste parents en vereiste children. De acties in Figuur 6-23(a) moeten worden 
ondernomen voor M-O- en M-M-relaties. De acties in Figuur 6-23(b) moeten worden 
ondernomen voor O-M- en M-M-relaties. 

Verplichte parents kunnen worden afgedwongen door de toepasselijke referen- 
tial integrity constraint te definiëren en de externe sleutel op null in te stellen. De 
ontwerper moet opgeven of het bijwerken van waarden in de primaire sleutel van 
de parent cascading zal worden doorgegeven of verboden, of verwijderingen uit de 
parent cascading zullen worden doorgegeven of verboden en welk beleid er zal wor- 
den gebruikt voor het vinden van een parent als er een nieuwe child wordt gemaakt. 

Het handhaven van verplichte children is moeilijk en vereist het gebruik van trig- 
gers of toepassingscode. Figuur 6-23(b) laat zien welke specifieke acties er moeten 
worden ondernomen. Het handhaven van M-M-relaties kan heel moeilijk zijn. Voor- 

al het maken van de eerste parent/child-rijen en het verwijderen van de laatste pa- 
rent/child-rijen kan een hele uitdaging zijn. De triggers op de beide tabellen zitten 
elkaar in de weg. M-M-relaties tussen sterke en zwakke entiteiten zijn minder pro- 
blematisch dan die tussen sterke entiteiten. 

De acties voor het handhaven van vereiste parents worden in dit boek gedocu- 
menteerd met behulp van referential integrity-acties in de ontwerpdiagrammen van 
de tabellen. De acties voor het handhaven van vereiste children worden gedocumen- 
teerd door Figuur 6-23(b) als een documentsjabloon te gebruiken. Een extra compli- 
catie is dat een tabel aan veel relaties kan deelnemen. Triggers die zijn geschreven 
voor het afdwingen van de minimumkardinaliteit van de ene relatie, kunnen in bot- 
sing komen met triggers die zijn geschreven voor het afdwingen van de minimum- 
kardinaliteit van een andere relatie. Dat probleem valt buiten het bereik van dit boek, 
maar je moet je ervan bewust zijn dat dit probleem bestaat. De principes voor het 
handhaven van de minimumkardinaliteit zijn samengevat in Figuur 6-29. 

Je ziet een databaseontwerp voor galerie View Ridge in Figuur 6-33. Je moet dat 
ontwerp begrijpen, want we gebruiken het in de rest van dit boek. 


Belangrijke termen 

alternatieve sleutel domain constraint 

cascading deletion galerie View Ridge (VRG) 

cascading update interrelation constraint 

data constraint intersectietabel 

defaultwaarde intrarelation constraint 
226 


DATAMODELLEN OMZETTEN iN DATABASEONTWERPEN 


kandidaatsleutel range constraint 

MAG NIET (MUST NOT) constraint surrogaatsleutel 

MOET (MUST) constraint trapsgewijze verwijdering 

MOET OMVATTEN (MUST COVER) trapsgewijze wijziging 
constraint trigger 

nullstatus tussentabel 

Oefeningen 


E 


Le) 


OD oon new 


Ln En! 
a, 


19. 


20. 


21. 


22. 
23. 


24. 
25. 


o 


Noem de drie hoofdtaken voor het omzetten van een datamodel in een 
databaseontwerp. 

Wat is de relatie tussen entiteiten en tabellen? En tussen attributen en 
kolommen? 

Waarom is de keuze van de primaire sleutel belangrijk? 

Wat zijn de drie kenmerken van een ideale primaire sleutel? 

Wat is een surrogaatsleutel? Wat zijn de voordelen daarvan? 

Waarom zou je een surrogaatsleutel gebruiken? 

Beschrijf twee nadelen van surrogaatsleutels. 

Wat is het verschil tussen een alternatieve sleutel en een kandidaatsleutel? 

Wat betekent de notatie AKn.m? 

Noem vier eigenschappen van kolommen. 

Leg uit waarom primaire sleutels nooit NULL kunnen zijn, maar alternatieve 
sleutels wel. 

Noem vijf algemene datatypen. 

Beschrijf drie manieren waarop een defaultwaarde kan worden toegekend. 

Wat is een domain constraint? Geef een voorbeeld. 

Wat is een range constraint? Geef een voorbeeld. 

Wat is een intrarelation constraint? Geef een voorbeeld. 

Wat is een interrelation constraint? Geen een voorbeeld. 

Welke taken moeten er worden uitgevoerd tijdens het controleren van de nor- 
malisatie van een databaseontwerp? 

Beschrijf twee manieren voor het representeren van een r:1 sterke entiteiten- 
relatie. Bedenk zelf een voorbeeld. 

Beschrijf hoe een r:N sterke entiteitenrelatie wordt gerepresenteerd. Bedenk 
zelf een voorbeeld. 

Beschrijf hoe een N:M sterke entiteitenrelatie wordt gerepresenteerd. Bedenk 
zelf een voorbeeld. 

Wat is een intersectietabel? Waarom is deze nodig? 

Wat is het verschil tussen de tabel die een ID-afhankelijke associatie-entiteit re- 
presenteert en een intersectietabel? 

Noem vier toepassingen voor ID-afhankelijke entiteiten. 

Beschrijf hoe een associatierelatie wordt gerepresenteerd. Bedenk zelf een voor- 
beeld van een dergelijke relatie. 
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26. Beschrijf hoe een entiteitenrelatie met meerwaardige attributen wordt gerepre- 
senteerd. Bedenk zelf een voorbeeld van een dergelijke relatie. 

27. Beschrijf hoe een supertype/subtype-entiteitenrelatie wordt gerepresenteerd. 
Bedenk zelf een voorbeeld van een dergelijke relatie. 

28. Wat gebeurt er wanneer een instantie-entiteit een niet [D-afhankelijke identifier 
krijgt? Welke invloed heeft deze wijziging op het ontwerp van de relatie? 

29. Wat gebeurt er als de parent in een ID-afhankelijke relatie een surrogaatsleutel 
krijgt? Wat moet er als de sleutel van de child worden gebruikt? 

30. Beschrijf hoe een gemengde entiteitenrelatie wordt gerepresenteerd. Bedenk 
zelf een voorbeeld van een dergelijke relatie. 

31. Beschrijf twee manieren voor het representeren van een 1:1 recursieve relatie. 
Bedenk zelf een voorbeeld van een dergelijke relatie. 

32. Beschrijf hoe een r:N recursieve relatie wordt gerepresenteerd. Bedenk zelf een 
voorbeeld van een dergelijke relatie. 


33. Beschrijf hoe een N:M recursieve relatie wordt gerepresenteerd. Bedenk zelf 
een voorbeeld van een dergelijke relatie. 
34. Beschrijf in het algemeen hoe ternaire relaties worden gerepresenteerd. Leg uit 
welke invloed een binaire voorwaarde op een dergelijke relatie kan hebben. 
35. Beschrijf een MOET-voorwaarde. Bedenk daar zelf een voorbeeld van. 
36. Beschrijf een MAG NIET-voorwaarde. Bedenk daar zelf een voorbeeld van. 
37. Beschrijf een MOET OMVATTEN-voorwaarde. Bedenk daar zelf een voorbeeld 
van. 
38. Leg in algemene termen uit wat er gedaan moet worden om de minimumkardi- 
naliteit te handhaven. 
39. Leg uit waarom elk van de acties uit Figuur 6-23(a) nodig is. 
40. Leg uit waarom elk van de acties uit Figuur 6-23(b) nodig is. 
41. Geef op welke van de acties uit Figuur 6-23 moeten worden toegepast op M-O- 
relaties, welke op O-M-relaties en welke op M-M-relaties. 
42. Leg uit wat er moet worden gedaan om vereiste parents te laten handhaven door 
het DBMS. 


43. Welke ontwerpbeslissingen moeten er genomen worden om vereiste parents te 
handhaven? 


44. Leg uit waarom het DBMS niet bruikbaar is voor het handhaven van vereiste 
children. 


45. Wat is een trigger? Hoe kunnen triggers gebruikt worden voor het handhaven 
van vereiste children? 


46. Leg uit waarom vooral M-M-relaties erg moeilijk te handhaven zijn. 
47. Leg uit waarom elk van de ontwerpbeslissingen uit Figuur 6-29 nodig is. 
48. Leg uit wat de reden is voor elk van de items in de tabel uit Figuur 6-35. 


Projectvragen 


49. Beantwoord vraag 49 uit hoofdstuk 5 (aanmeldformulier), als je dat nog niet hebt 
gedaan. Ontwerp een database voor jouw model uit vraag 49 van hoofdstuk 5. 
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Het ontwerp moet specificaties omvatten voor tabellen en attributen, evenals 
primaire sleutels, kandidaatsleutels en externe sleutels. Geef ook op hoe je de 
minimumkardinaliteit handhaaft. Documenteer het handhaven van de mini- 
mumkardinaliteit voor eventuele vereiste parents met referential integrity-acties 
en voor eventuele vereiste children met het schema uit Figuur 6-23(b). 
Beantwoord vraag so uit hoofdstuk 5 (bekeuring). Ontwerp een database voor 
jouw model. Het ontwerp moet specificaties omvatten voor tabellen en attribu- 
ten, evenals primaire sleutels, kandidaatsleutels en externe sleutels. Geef ook op 
hoe je de minimumkardinaliteit handhaaft. Documenteer het handhaven van de 
minimumkardinaliteit voor eventuele vereiste parents met referential integrity- 
acties en voor eventuele vereiste children met het schema uit Figuur 6-23(b). 
Beantwoord vraag 51 uit hoofdstuk 5 (e-mail). Ontwerp een database voor jouw 
model uit vraag s1 WORDT (c) van hoofdstuk 5. Het ontwerp moet specificaties 
omvatten voor tabellen en attributen, evenals primaire sleutels, kandidaatsleu- 
tels en externe sleutels. Geef ook op hoe je de minimumkardinaliteit handhaaft. 
Documenteer het handhaven van de minimumkardinaliteit voor eventuele ver- 
eiste parents met referential integrity-acties en voor eventuele vereiste children 
met het schema uit Figuur 6-23(b). 

Beantwoord vraag 52 uit hoofdstuk 5 (aandelenkoersen). Ontwerp een database 
voor jouw model uit vraag 52(d) van hoofdstuk 5. Het ontwerp moet specificaties 
omvatten voor tabellen en attributen, evenals primaire sleutels, kandidaatsleu- 
tels en externe sleutels. Geef ook op hoe je de minimumkardinaliteit handhaaft. 
Documenteer het handhaven van de minimumkardinaliteit voor eventuele ver- 
eiste parents met referential integrity-acties en voor eventuele vereiste children 
met het schema uit Figuur 6-23(b). 

Beantwoord vraag 53 uit hoofdstuk 5 (luchtcompressor). Ontwerp een database 
voor jouw model uit vraag 53(a) van hoofdstuk 5 en een database voor het model 
uit Figuur 5-33. De ontwerpen moeten specificaties omvatten voor tabellen en 
attributen, evenals primaire sleutels, kandidaatsleutels en externe sleutels. Geef 
ook op hoe je de minimumkardinaliteit handhaaft. Documenteer het handha- 
ven van de minimumkardinaliteit voor eventuele vereiste parents met referenti- 
al integrity-acties en voor eventuele vereiste children met het schema uit Figuur 
6-23(b). 

Beantwoord vraag 54 uit hoofdstuk 5 (filmvoorstelling). Ontwerp een database 
voor jouw model uit vraag 54(e) van hoofdstuk 5. Het ontwerp moet specificaties 
omvatten voor tabellen en attributen, evenals primaire sleutels, kandidaatsleu- 
tels en externe sleutels. Geef ook op hoe je de minimumkardinaliteit handhaaft. 
Documenteer het handhaven van de minimumkardinaliteit voor eventuele ver- 
eiste parents met referential integrity-acties en voor eventuele vereiste children 
met het schema uit Figuur 6-23(b). 

Beantwoord vraag 55 uit hoofdstuk 5 (Kellog’s). Ontwerp een database voor jouw 
model uit vraag 5s(c) van hoofdstuk 5. Het ontwerp moet specificaties omvat- 
ten voor tabellen en attributen, evenals primaire sleutels, kandidaatsleutels 
en externe sleutels. Geef ook op hoe je de minimumkardinaliteit handhaaft. 
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Documenteer het handhaven van de minimumkardinaliteit voor eventuele ver- 
eiste parents met referential integrity-acties en voor eventuele vereiste children 
met het schema uit Figuur 6-23(b). 

56. Beantwoord vraag 56 uit hoofdstuk 5 (cd-hoes). Ontwerp een database voor jouw 
model uit vraag 56(d) van hoofdstuk 5. Het ontwerp moet specificaties omvat- 
ten voor tabellen en attributen, evenals primaire sleutels, kandidaatsleutels en 
externe sleutels. Geef ook op hoe je de minimumkardinaliteit handhaaft. Docu- 
menteer het handhaven van de minimumkardinaliteit voor eventuele vereiste 
parents met referential integrity-acties en voor eventuele vereiste children met 
het schema uit Figuur 6-23(b). 


Marcia’s Chemische Reiniging 


Maak het project Marcia's Chemische Reiniging aan het eind van hoofdstuk 5 af, als 

je dat niet al deed. Ontwerp een database voor het model uit je antwoord. Je ontwerp 
moet specificaties omvatten voor tabellen en attributen en moet primaire sleutels, 
kandidaatsleutels en externe sleutels opgeven. Geef ook op hoe je de minimum: 
kardinaliteit handhaaft. Documenteer het afdwingen van de minimumkardinaliteit 
met referential integrity-acties voor eventuele vereiste parents en met het schema uit 
Figuur 6-23(b) voor eventuele vereiste children. 


Importbedrijf Morgan 


Maak het project Importbedrijf Morgan aan het eind van hoofdstuk 5 af, als je dat 
niet al deed. Ontwerp een database voor het model uit je antwoord. Je ontwerp moet 
specificaties omvatten voor tabellen en attributen en moet primaire sleutels, kan- 
didaatsleutels en externe sleutels opgeven. Geef ook op hoe je de minimumkardi- 
naliteit handhaaft. Documenteer het afdwingen van de minimumkardinaliteit met 
referential integrity-acties voor eventuele vereiste parents en met het schema uit 
Figuur 6-23(b) voor eventuele vereiste children. 
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Databases implementeren 


Deel 3 bestaat uit twee hoofdstukken. Hoofdstuk 7 beschrijft SQL data definition 
language (DDL)-statements voor het maken van onderdelen van databases. Het be- 
schrijft ook de SQL data manipulation language (DML)-statements INSERT, UPDATE 
en DELETE. Je leert hoe je SQL-views maakt en gebruikt en hoe je SQL-statements in 
programma’s inbouwt. Het hoofdstuk sluit af met een toelichting van triggers en 
opgeslagen procedures. 

Hoofdstuk 8 presenteert het gebruik van SQl-statements voor het herontwerpen 
van databases. Het behandelt gecorreleerde subquery’s en EXISTS/NOT EXISTS-state- 
ments - twee geavanceerde SQL-statements die nodig zijn voor het herontwerpen 
van databases. Hoofdstuk 8 beschrijft ook reverse engineering, geeft een overzicht 
van veelvoorkomende problemen bij het herontwerpen van databases en laat zien 
hoe we SQL kunnen gebruiken voor het oplossen van deze problemen. 
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Hoofdstuk 7 
SQL voor het maken van 
databases 


We introduceerden SQL in hoofdstuk 2 en deelden SQL-statements in twee categorieën 
in: data manipulation language (DML)-statements, die worden gebruikt voor het uit- 
voeren van query’s en het wijzigen van gegevens, en data definition language (DDL)- 
statements, die worden gebruikt voor het maken van tabellen, relaties en andere 
structuren. In hoofdstuk 2 bespraken we alleen DML-querystatements. 

Dit hoofdstuk beschrijft en illustreert SQL DOL-statements voor het invoegen, wij- 
zigen en verwijderen van gegevens. We beschrijven ook hoe SQL-views worden ge- 
maakt, hoe SQL-statements in applicaties worden ingebouwd en hoe SQL gebruikt 
wordt in triggers en opgeslagen procedures. 

De kennis in dit hoofdstuk is belangrijk, ongeacht of je nu een databasebeheerder 
of een applicatieprogrammeur wordt. Het is belangrijk dat je weet wat triggers en op- 
geslagen procedures zijn, hoe ze werken en hoe ze de databaseverwerking beïnvloe- 
den, ongeacht of je ze zelf zult schrijven of niet. 
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7.1 De database van View Ridge 


In het vorige hoofdstuk introduceerden we galerie View Ridge (VRG), een kleine 
kunstgalerie die hedendaagse kunst uit Noord-Amerika en Europa verkoopt en een 
afdeling heeft voor het inlijsten van schilderijen. We ontwikkelden voor deze galerie 
een datamodel en een database. De uiteindelijke database zie je in Figuur 7-1. 


CUSTOMER 
CustomerlD 

Pr en ARTIST 
LastName VERKOCHT VERWORVEN [Q workiD XY ArtistiD 
Ee si î Tt LastName (AK1.1) 
AreaCode Gn DateAcquired PT" Title (AK1.1) £ EEn 
LocalNumber AcquisitionPrice Copy (AK1.2) FirstName ( +1) 
Street DateSold Medium Nationality 
City SalesPrice Description DateOfBirth 
State rra ArtistID (FK) DateDeceased 

: WorkID (F se 

Zphostigode CustomerlD (FK) 
Country 


Email (AK1.1) 
CUSTOMER_ARTIST_INT 


SN CustomerlD (FK) 
SN ArtistiD (FK) bs 


Figuur 7-1 Uiteindelijk ontwerp VRG-database 


d 
Sj 
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In dit hoofdstuk gebruiken we SQL om de VRG-database te bouwen op grond van 
dit ontwerp. 


7.2 SQL DDL, DML en een nieuw type join 


Figuur 7-2 geeft een overzicht van de nieuwe SQL-statements die we in dit hoofdstuk 
bespreken. We beginnen met SQL DDL-statements voor het beheren van tabelstruc- 
turen, waaronder CREATE TABLE, ALTER TABLE en DROP TABLE. Met behulp van 
deze statements zullen we de tabelstructuur voor VRG-database maken. 

Daarna introduceren we de drie SQL DML-statements om gegevens te manipule- 
ren: INSERT, UPDATE en DELETE. Ten slotte breiden we de kennis van joins die je 
in hoofdstuk 2 opdeed uit door een nieuw soort join te beschrijven. 


« SQL Data Definition Language (DDL) 
— CREATE TABLE 
— ALTER TABLE 
— DROP TABLE 
e SQL Data Manipulation Language (DML) 
— INSERT 


— UPDATE 
— DELETE 
e Andere join-vormen 
— Altematieve syntaxis voor joins 
— Outer joins 


Figuur 7-2 In dit hoofdstuk behandelde SQL-statements 
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7.3 De tabelstructuur beheren met SQL DDL 


Het SQL-statement CREATE TABLE gebruiken we voor het maken van tabellen, het 
definiëren en opleggen van eisen aan kolommen, en het maken van relaties. De 
meeste DBMS-producten bieden grafische tools voor het uitvoeren van deze taken 
en je kunt je afvragen waarom je SQL moet leren om hetzelfde werk te doen. Daar 
zijn vier redenen voor. 

Ten eerste gaat het maken van tabellen en relaties sneller met SQL dan met gra- 
fsche tools. 

Als je eenmaal weet hoe het SQL-statement CREATE TABLE werkt, kun je sneller 
en makkelijker tabellen maken met SQL dan via knoppen en grafische handigheid- 
jes. Ten tweede vereisen sommige applicaties, vooral die voor rapportage, querying 
en datamining, dat je dezelfde tabel meerdere keren maakt. Je doet dat op een effi- 
ciënte manier door een tekstbestand te maken met de nodige SQL CREATE TABLE- 
statements. Ten derde vereisen sommige applicaties dat je tijdelijke tabellen maakt. 
De enige manier om dat te doen, is het gebruik van SQL. Ten vierde is SQL DDL re- 
delijk standaard en min of meer onafhankelijk van het DBMS. 


7.3.1 DE VRG-database maken 

Voordat je een tabel kunt maken, moet je eerst een database creëren. SQL-92 heeft 
daarvoor een statement, maar dat wordt zelden gebruikt. In plaats daarvan gebrui- 
ken de meeste ontwikkelaars speciale opdrachten of grafische tools om een database 
te maken. Deze technieken zijn DBMS-afhankelijk. 

Op dit moment raden we je aan deze paragraaf te lezen over het maken van een 
database en met het DBMS waarover je beschikt de nodige stappen te zetten om een 
nieuwe database te maken met de naam VRG. Om een en ander te illustreren, ge- 
bruiken we in dit hoofdstuk SQL Server 2008 en de gebruikte SQL-code is de code 
voor SQL Server. De correcte SQL-statements voor andere DBMS producten zijn ver- 
gelijkbaar, maar zullen iets verschillen. In Figuur 7-3 zie je de VRG-database in SQL 
Server 2008 Management Studio. 


7.3.2 Variaties in datatypen 

Elk DBMS heeft zijn eigen variant van SQL. Een van de verschillen bestaat uit het ge- 
bruik van verschillende datatypen. In Figuur 7-4 zie je de datatypen van SQL Server. 
Als je een ander DBMS gebruikt, raadpleeg dan de betreffende documentatie voor 
de geldige datatypen. 
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Het VRG- 
databaseobject 


De mappen van 
VRG, databaseobjecten 
als tabellen komen in 

deze mappen 


ey 


Figuur 7-3 De VRG-database in SQL Server 2008 Management Studio 


[Beschrijving 
Binair, lengte van 0 tot 8000 bytes. kk pe 
Tekens, lengte van 0 tot 8000 bytes. es: . De 4 

Datetime Datum en tijd, 8 bytes. Bereik van 1 januari 1753 tot en met 31 december 9999, met | 


[een nauwkeurigheid van een driehonderdste seconde. _ Î | 
Image | Binaire gegevens met variabele lengte. Maximale lengte: 2.147.483.647 bytes 
Integer Integer, 4 bytes. Waardebereik van -2.147.483.648 tot en met 2.147.483.647. 


Money Geldwaarde, 8 bytes. Bereik van -922.337.203.685.477,5808 tot en met 
+922.337.203.685.477,5807, met een nauwkeurigheid van een tienduizendste 
eenheid. | 
Decimaal, met instelbare precisie en schaal. Bereik van -10°38 + 1 tot en met 
10°38 - 1. 

Datum en tijd, 4 bytes. Bereik van 1 januari 1900 tot en met 6 juni 2079, met een 
nauwkeurigheid van een minuut. 

Integer, 2 bytes. Bereik van -32.768 tot en met 32.767. | 
Geldwaarde, 4 bytes. Bereik van 214.748,3648 tot en met +214.748,3647, met een 
nauwkeurigheid van een tienduizendste eenheid. 

Tekst met variabele lengte. Maximale lengte 2.147.483.647 tekens. 

Integer, 1 byte. Bereik van 0 tot en met 255. 

Tekens met variabele lengte. Lengte van 0 tot 8000 bytes. 


Smalldatetime 


Smallint 


Smallmoney 


Varchar 


Figuur 7-4 Datatypen van SQL Server 


7.3.3 De tabel ARTIST maken 

Figuur 7-5 toont twee van de tabellen uit het ontwerp voor View Ridge dat we aan het 
eind van hoofdstuk 6 ontwikkelden. Deze figuur toont de datatypen en de nulleigen- 
schappen voor elke kolom. Het enige nieuwe kenmerk is het datatype IDENTITY, dat 
wordt gebruikt voor het aangeven van een surrogaatsleutel. De uitdrukking IDENT]- 
TY (11) betekent dat ArtistID een surrogaatsleutel is met een waarde die bij 1 begint 
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en met r wordt opgehoogd. De uitdrukking IDENTITY (5oo,1) in de tabel WORK be- 
tekent dat WorklD een surrogaatsleutel moet zijn, met waarden die beginnen bij soo 
en oplopen met 1. De waarde voor de tweede rij van WORK zal dus sor zijn. 


Column Name | Type NULL Status 


ET 
ArtistlD Int Primary Key NOT NULL Surrogate Key 
IDENTITY (1,1) 
LastName Char (25) Alternate Key | NOT NULL 
| FirstName Char (25) Alternate Key | NOT NULL 


Nationality 
DateOfBirth 


Char (30) NULL 


Numeric (4) 


DateDeceased Numeric (4) 


Int 


Column Name 


WorkID Primary Key NOT NULL Surrogate Key 
IDENTITY (500,1) 
Title Char (35 NOT NULL 


) 
Char (12) 
Char (35) 


Medium 


Description Varchar DEFAULT 
(1000) value = 
‘Unknown 


No 
No 
No 
No 
ArtistID li Foreign Key | NOT NULL 


Figuur 7-5 De tabellen ARTIST en WORK uit het ontwerp voor galerie View Ridge 


provenance’ 


Opmerking 

Verschillende DBMS-producten definiëren surrogaatsleutels op verschillende manieren. Het hier getoonde 
sleutelwoord IDENTITY werkt voor SQL Server. Oracle, MySQL en Access gebruiken iets andere technieken. 
Alle SQL die je in dit hoofdstuk ziet, werkt met SQL Server. Je moet misschien een paar aanpassingen 
uitvoeren als je een ander DBMS gebruikt. Raadpleeg de documentatie van het DBMS dat je gebruikt als 
je problemen ondervindt met een van de hier getoonde SQL-statements. 


Figuur 7-6 toont het CREATE TABLE-statement voor het maken van de tabel ARTIST. 
De indeling van CREATE TABLE is de naam van de tabel, gevolgd door een lijst van 
alle kolomdefinities en -constraints, ingesloten tussen haakjes en eindigend met een 
puntkomma. 
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CREATE TABLE ARTIST ( 
ArtistiD Int NOT NULL IDENTITY (1,1), 
LastName Char (25) NOT NULL, 
FirstName Char (25) NOT NULL, 
Nationality Char (30) NULL, 
DateOfBirth Numeric (4) NULL, 
DateDeceased Numeric (4) NULL, 
CONSTRAINT ArtistPK PRIMARY KEY (Artist1D), 
CONSTRAINT ArtistAK1 UNIQUE (LastName, FirstName) 
) 


Figuur 7-6 SQL voor het maken van de eerste versie van de tabel ARTIST 


SQL kent verscheidene constraints: PRIMARY KEY, NULL, NOT NULL, UNIQUE, 
FOREIGN KEY en CHECK. Het doel van de eerste vier constraints ligt voor de hand. 
FOREIGN KEY wordt gebruikt voor het definiëren van referentiële integriteitsvoor- 
waarden. CHECK wordt gebruikt voor het definiëren van data constraints. 

In het eerste deel van het CREATE TABLE-statement wordt elke kolom gedefi- 
nieerd door de naam, het datatype en de nulltoestand ervan op te geven. Er wordt 
NULL aangenomen als je geen NULL of NOT NULL opgeeft. 

In deze database is de waarde van DateOfBirth en van DateDeceased een jaartal. 
BirthYear en DeceasedYear zouden betere kolomnamen zijn geweest, maar dat is 
niet hoe het personeel van de galerie ze noemt. De galerie is niet geïnteresseerd in de 
dag en maand van de geboorte- en overlijdensdatum van een kunstenaar. Deze ko- 
lommen zijn daarom gedefinieerd als Numeric(4,o) — dat wil zeggen: een getal met 
vier cijfers, zonder cijfers achter de komma. 

De laatste twee expressies in de tabeldefinitie in Figuur 7-6 zijn constraints die 
de primaire en een kandidaat- of alternatieve sleutel definiëren. Het voornaamste 
doel van een alternatieve sleutel is, zoals je al in hoofdstuk 6 zag, te garanderen dat 
kolomwaarden uniek zijn. Alternatieve sleutels worden daarom in SQL gedefinieerd 
met de constraint UNIQUE. 

De indeling van dergelijke constraints is het woord CONSTRAINT, gevolgd door 
een door de ontwikkelaar geleverde naam van een constraint, gevolgd door PRIMA- 
RY KEY of door UNIQUE en dan door een of meer tussen haakjes geplaatste kolom:- 
namen. Het volgende statement definieert bijvoorbeeld een constraint met de naam 
Mijn Voorbeeld, die zeker stelt dat de combinatie van de voor- en achternaam uniek is: 


CONSTRAINT MijnVoorbeeld UNIQUE (Voornaam, Achternaam) 


Zoals we al in hoofdstuk 6 vermeldden, moeten primaire sleutels NOT NULL zijn, 
maar kunnen kandidaat-sleutels NULL of NOT NULL zijn. 

Merk op dat de laatste regel van het SQL-statement bestaat uit een sluitend haak- 
je, gevolgd door een puntkomma. Deze tekens zouden we ook in de regel erboven 
kunnen opnemen, maar het is een stijlconventie om ze in een eigen regel te plaat- 
sen. Dat maakt het makkelijk de grenzen van CREATE TABLE-statements te be- 
palen. Merk ook op dat de constraints voor het beschrijven van kolommen door 
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komma's van elkaar zijn gescheiden, maar dat er geen komma achter de laatste con- 
straint staat. 

SQL stamt uit de tijd dat ponskaarten gebruikt werden voor gegevensverwerking. 
Een ponskaart gebruikt alleen hoofdletters. Toen ponskaarten werden vervangen 
door gewone toetsenborden besloten DBMS-leveranciers het onderscheid tussen 
hoofd- en kleine letters te negeren, met als gevolg dat CREATE TABLE, create table 
en CReatE taBle in SQL hetzelfde zijn. Dat geldt ook voor NULL, null en Null. 


Opmerking 

Veel organisaties ontwikkelden eigen SQl-codestandaarden. Dergelijke standaarden specificeren niet 
alleen de indeling van SQL-statements, maar ook conventies voor de naamgeving van constraints. We 
gebruiken in de figuren in dit hoofdstuk bijvoorbeeld het achtervoegsel PK (voor Primary Key) in de 
namen van alle primary key constraints, en het achtervoegsel FK voor alle foreign key constraints. 


7.3.4 De tabel WORK en de 1:N-relatie ARTIST-WORK maken 
Figuur 7-7 toont de SQL-statements voor het maken van de tabellen ARTIST en 
WORK en van hun relatie. 


CREATE TABLE ARTIST ( 


ArtistlD Int NOT NULL IDENTITY (1,1), 
LastName Char (25) NOT NULL, 
FirstName Char (25) NOT NULL, 
Nationality Char (30) NULL, 
Dateof Birth Numeric (4) NULL, 
DateDeceased Numeric (4) NULL, 
CONSTRAINT ArtistPK PRIMARY KEY (ArtistID), 
CONSTRAINT ArtistAK1 UNIQUE (LastName, FirstName) 
); 

CREATE TABLE WORK ( 
WorklD Int NOT NULL IDENTITY (500, 1), 
Title Char (35) NOT NULL, 
Copy Char (12) NOT NULL, 
Medium Char (35) NULL, 
(Description) Varchar (1000) NULL DEFAULT ‘Unknown provenance’. 
Artist ID Int NOT NULL, 
CONSTRAINT _ WorkPK PRIMARY KEY (WorkID), 
CONSTRAINT _ WorkAK1 UNIQUE (Title, Copy), 
CONSTRAINT _ ArtistFK FOREIGN KEY (ArtistID) 


REFERENCES ARTIST (ArtistlD) 
ON UPDATE NO ACTION 
ON DELETE NO ACTION 


); 


Figuur 7-7 SQL voor het maken van de 1:N-relatie tussen ARTIST en WORK 
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Merk op dat de kolomnaam Description geschreven is als [Description]. Dit is omdat 
Description in SQL Server 2008 een gereserveerd woord is. Om een dergelijke re- 
den gebruikten we in hoofdstuk 6 de naam TRANS in plaats van TRANSACTION. 

De enige nieuwe syntaxis in Figuur 7-7 is de FOREIGN KEY-constraint aan het 
eind van WORK. Dergelijke constraints worden gebruikt voor het definiëren van re- 
ferential integrity constraints. De FOREIGN KEY-constraint in Figuur 7-7 komt over- 
een met de volgende referentiële integriteitsvoorwaarde: 


WORK.ArtistID moet bestaan in ARTIST.ArtistID 


De externe key constraint bevat een clausule die specificeert of updates of verwijde- 
ringen al dan niet cascading moeten worden uitgevoerd. De expressie DELETE NO 
ACTION geeft aan dat het verwijderen van rijen die children hebben, moet worden 
verboden. De expressie DELETE CASCADE zou aangeven dat verwijderingen traps- 
gewijs moeten worden uitgevoerd. DELETE NO ACTION is de standaard. 

De expressie UPDATE NO ACTION geeft op een soortgelijke manier aan dat up- 
dates verboden moeten worden voor de primaire sleutel van een tabel die children 
heeft. De expressie UPDATE CASCADE zou aangeven dat updates cascading moe- 
ten worden uitgevoerd. UPDATE NO ACTION is de standaard. 

De UPDATE NO ACTION is in het huidige geval betekenisloos, want de sleutel 
van ARTIST is een surrogate key en zal nooit veranderen. De UPDATE-actie zou 
echter moeten worden opgegeven voor data keys. We laten deze optie hier zien, zodat 
je weet hoe je ze moet schrijven. 


Opmerking 
Merk op dat je eerst parent-tabellen moet definiëren voordat je child-tabellen kunt definiëren. Je moet in 
dit geval eerst ARTIST definiëren, voordat je WORK definieert. Het DBMS levert een foutmelding over de 


FOREIGN KEY-constraint als je deze volgorde probeert om te draaien, omdat het de tabel ARTIST dan nog 
niet kent. 


Verder geldt dat tabellen in de omgekeerde volgorde moeten worden verwijderd. Je moet een child 
verwijderen met de (verderop beschreven) opdracht DROP voordat je de parent verwijdert. 
Betere SQL-parsers zoeken dat allemaal zelf uit, zodat de volgorde van de statements niet uitmaakt. Dat is 


jammer genoeg echter niet hoe het gedaan wordt. Onthoud gewoon het volgende: de ouders komen het 
eerst en gaan het laatst weg. 


7.3.5 Vereiste parent-rijen implementeren 
Je leerde in hoofdstuk 6 dat je om een vereiste parent af te dwingen de referential 
integrity constraint moet definiëren en de foreign key op NOT NULL moet instel- 
len. De code in Figuur 7-7 doet beide. Er wordt NOT NULL opgegeven voor WORK. 
ArtistID en de referentiële integriteit wordt gedefinieerd door de FOREIGN KEY- 
constraint. Hiermee wordt dus de vereiste parent afgedwongen. 

Als de parent niet vereist was, zouden we NULL opgeven voor WORK.ArtistID. 
In dat geval zou WORK geen waarde voor ArtistID hoeven te hebben — en dus ook 
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geen parent. De FOREIGN KEY-constraint zou echter nog steeds garanderen dat alle 
waarden van WORK.ArtistID in ARTIST. ArtistID zouden voorkomen. 


7.3.6 1:1-relaties implementeren 

SQL voor het implementeren van r:1-relaties is vrijwel hetzelfde als die voor r:N-re- 
laties. Het enige verschil is dat de foreign key uniek moet zijn. Als bijvoorbeeld de 
relatie tussen ARTIST en WORK r:1 was (dat wil zeggen: dat elke artiest maar één 
werk bij View Ridge kan hebben), dan zouden we de volgende constraint aan Figuur 
7-7 toevoegen: 


CONSTRAINT UniqueWork UNIQUE (ArtistID) 


In werkelijkheid is de relatie natuurlijk niet r:1 en we zullen deze constraint dus ook 
niet opgeven. Als de parent vereist is, moet de foreign key op NOT NULL worden 
ingesteld, en op NULL als dat niet het geval is. 


7.3.7 Losse relaties 

We kunnen soms een foreign key-kolom maken zonder dat we een FOREIGN KEY- 
constraint opgeven. De foreign key komt in dat geval al dan niet overeen met een 
waarde van de primaire sleutel in de parent. Definieer je bijvoorbeeld de kolom Afde- 
lingsnaam in WERKNEMER, maar geen FOREIGN KEY-constraint, dan kan een rij 
een waarde van Afdelingsnaam hebben die al dan niet overeenkomt met een waarde 
van Afdelingsnaam in de tabel AFDELING. 

Dergelijke relaties, die we losse relaties zullen noemen, komen vaak voor in ap- 
plicaties die tabellen verwerken waarin gegevens ontbreken. Je kunt bijvoorbeeld 
consumentengegevens kopen die de namen van de werkgevers van de consumenten 
omvatten. Neem aan dat je een tabel WERKGEVER hebt, die niet alle mogelijke be- 
drijven bevat waar consumenten voor kunnen werken. Maak in dat geval een losse 
relatie door de sleutel van WERKGEVER in de tabel met consumentengegevens op 
te nemen, maar geen FOREIGN KEY-constraint te definiëren. 

Figuur 7-8 geeft een overzicht van de technieken voor het maken van relaties met 
FOREIGN KEY-, NULL/NOT NULL- en UNIQUE-constraints. 


CREATE TABLE-constraints 
Geef FOREIGN KEY-constraint op. Stel de foreign key in op NULL. 
Geef FOREIGN KEY-constraint op. Stel de foreign key in op NOT NULL. 
Geef FOREIGN KEY-constraint op. Geef UNIQUE-constraint op voor de 
foreign key. Stel de foreign key in op NULL. 

Geef FOREIGN KEY-constraint op. Geef UNIQUE-constraint op voor de 
foreign key. Stel de foreign key in op NOT NULL. 

Maak een foreign key-kolom, maar geef geen FOREIGN KEY-constraint 
op. Specificeer UNIQUE voor de foreign key als de relatie 1:1 is. 


Soort relatie 
1:N-relatie met optionele parent 
1:N-relatie met vereiste parent 

| 1:1-relatie met optionele parent 


1:1-relatie met vereiste parent 


Losse relatie 


Figuur 7-8 Overzicht van met CREATE TABLE te maken relatiedefinities 
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7.3.8 Defaultwaarden en data constraints 

Figuur 7-9 toont een voorbeeld van een verzameling defaultwaarden en voorbeelden 
van data constraints voor de database van View Ridge. De kolom WORK.Descripti- 
on krijgt als defaultwaarde ‘Unknown provenance’ (herkomst onbekend). De rest van 
deze tabel laat data constraints zien. 


Kolom Defaultwaarde _ | nn Constraint sl 
Description ‘Unknown provenance’ | Ee Eel | 
Nationality [IN Canadian’, ‘English’, ‘French’, ‘German’, 

| r _| Mexican’, ‘Russian’, ‘Spanish’, ‘US’) Rl 

DateOf Birth eerder dan DateDeceased 
DateOf Birth Vier cijfers: eerste cijfer 1 of 2, overige drie | 
| cijfers O tot en met 9 B | 
DateDeceased Vier cijfers: eerste cijfer 1 of 2, overige drie | 
cijfers O tot en met 9 | 

SalesPrice |> 1000 en <= 200.000 __ 

DateSold | later dan DateAcquired 5 


Figuur 7-9 Defaultwaarden en data constraints voor View Ridge 


De nationaliteit van kunstenaars wordt beperkt tot op de waarden in de getoonde 
domeinconstraint. 

DateOfBirth wordt beperkt door de intrarelation constraint dat DateOfBirth eer- 
der moet zijn dan DateDeceased. DateOfBirth en DateDeceased, die zoals je al eerder 
zag een jaartal aangeven, worden beperkt tot op het domein dat wordt gedefinieerd 
door op te geven dat het eerste cijfer een r of een 2 kan zijn en dat de resterende drie 
cijfers willekeurige decimale cijfers kunnen zijn. Ze kunnen dus een willekeurige 
waarde hebben van 1ooo tot en met 2999. 

SalesPrice in de tabel TRANS wordt beperkt door de bereikconstraint en Date- 
Sold wordt beperkt door een intrarelatieconstraint die bepaalt dat de DateSold later 
moet zijn dan de DateAquired. 

Figuur 7-9 laat geen interrelatieconstraints zien. Er zijn weliswaar voorzieningen 
voor het maken van dergelijke constraints gedefinieerd in de specificaties van SQL- 
92, maar geen enkele DBMS-leverancier heeft deze voorzieningen geïmplemen- 
teerd. Zulke constraints moet je implementeren met behulp van triggers. Hier tonen 
we verderop in dit hoofdstuk een voorbeeld van. Figuur 7-1o laat de SQL-statements 
zien voor het maken van de tabellen ARTIST en WORK met de juiste defaultwaar- 
den en data constraints. 


7.3.9 Defaultwaarden implementeren 

Defaultwaarden worden gemaakt door het sleutelwoord DEFAULT op te geven in de 
kolomdefinitie. Dit sleutelwoord moet meteen volgen op NULL/NOT NULL. Zie bij- 
voorbeeld hoe in Figuur 7-10 WORK.Description de defaultwaarde “Unknown pro- 


venance’ krijgt. 
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7.3.10 Data constraints implementeren 

De data constraints worden gemaakt met behulp van CHECK-constraints. Deze be- 
ginnen met het woord CONSTRAINT, gevolgd door een door de ontwikkelaar gele- 
verde naam van een constraint, gevolgd door het woord CHECK en dan de tussen 
haakjes geplaatste specificatie van de constraint. Expressies in CHECK-constraints 
lijken op die in de WHERE-clausules van SQL-statements. Het sleutelwoord IN wordt 
gebruikt om een lijst van geldige waarden te leveren. NOT IN kan ook gebruikt wor- 
den om waarden uit te sluiten (niet in dit voorbeeld getoond). LIKE wordt gebruikt 
voor het opgeven van decimale plaatsen. Er worden bereikcontroles opgegeven met 
de groter-dan- en kleiner-dan-symbolen (<, >). Er kunnen alleen vergelijkingen wor- 
den uitgevoerd tussen kolommen in dezelfde tabel, omdat interrelatieconstraints 
niet worden ondersteund. 


ish’, ‘French’, ‘German’, 
‘United States')), 
irth < DateDeceased), 


\ LIKE CLE 9} CO - 9} CO OT}; 
eased LIKE * [1 - 2) [OQ 9) CO 91 ON) 
REATE T 
Int NTITY (500,1) 
Char 
har(8 
Char(35 
archar( 1000) FAULT “Inknown provenance, 


Artist ID Int 


WorkP« 


WorkA 
ArtistFK 
REFERENCES ARTIST (ArtistID) 
ON UPDATE NO ACTION 
ON DELETE KO ACTION 


Figuur 7-10 SQL voor het maken van de tabellen ARTIST en WORK, met data constraints 
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Opmerking 

DBMS-producten zijn niet consequent in de manier waarop ze CHECK-constraints implementeren. De 
LIKE-constraint in Figuur 7-10 zal bijvoorbeeld niet werken met Oracle. Oracle implementeert aan de 
andere kant weer andere soorten constraints. Je moet leren wat de eigenaardigheden zijn van het DBMS 
waarmee je werkt om te weten hoe je constraints het beste implementeert. 


7.3.11 De View Ridge-database maken 
Figuur 7-11 toont SQL voor het maken van alle tabellen van de aan het eind van 
hoofdstuk 6 gedocumenteerde database voor View Ridge. Lees elke regel en wees er 
zeker van dat je de functie en het doel ervan begrijpt. Merk op dat verwijderingen 
cascading worden uitgevoerd voor de relaties tussen CUSTOMER en CUSTOMER_ 
ARTIST_INT en tussen ARTIST en CUSTOMER_ARTIST_INT. 
De tabelnamen WORK en TRANS zijn tussen blokhaakjes geplaatst ([, J), omdat 
de woorden work en transaction gereserveerde woorden zijn voor de meeste DBMS- 
producten. Door ze tussen blokhaakjes te plaatsen, laten we de SQL-parser weten dat 
deze termen door de ontwikkelaar zijn geleverd en dat ze niet op de standaardmanier 
moeten worden gebruikt. SQL Server kan het woord WORK ironisch genoeg verwer- 
ken zonder dat dit problemen oplevert, maar Oracle kan dat niet. SQL Server verslikt 
zich daarentegen in het woord TRANS, waar Oracle weer geen probleem mee heeft. 
Je vindt een lijst van de gereserveerde woorden in de documentatie van het DB- 
MS-product dat je gebruikt. Je kunt er zeker van zijn dat je problemen krijgt als je een 
van de sleutelwoorden van de SQL-syntaxis, zoals SELECT, FROM, WHERE, LIKE, 
ORDER, ASC of DESC, gebruikt voor namen van tabellen of kolommen. Plaats der- 
gelijke woorden tussen blokhaakjes. Je maakt je leven echter eenvoudiger als je het 
helemaal kunt vermijden dergelijke namen te gebruiken voor tabellen of kolommen. 


De SQL-statements in Figuur 7-11 zullen alle tabellen voor de View Ridge database 
maken zoals die aan het einde van hoofdstuk 6 is beschreven. Lees elke regel en 
overtuig je ervan dat je de betekenis en het doel ervan begrijpt. Als je voor kolommen 
of tabellen namen gebruikt die in het DBMS gereserveerde woorden zijn, zet deze 
dan tussen blokhaken, zoals [Description]. 

Voorbeelden van gereserveerde woorden zijn FROM, WHERE, LIKE, ORDER, 
ASC, DESC. Omdat gereserveerde woorden per DBMS kunnen verschillen, moet je 
de betreffende documentatie raadplegen. 

Je DBMS zal alle tabellen, relaties en constraints voor de View Ridge-database 
genereren als je de SQL-statements uit Figuur 7-11 uitvoert. Figuur 7-12 toont de in 
SQL Server gegenereerde relaties. 

Je kunt deze tabellen en relaties veel makkelijker maken met SQL-code dan met 
grafische tools. 
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CREATE TABLE ARTIST 
onalityVvalues 
tionalit 
xican” 

ONSTRAINT BirthValuesCheck C 
CONSTRAINT ValidBirthYear CHE 
CONSTRAINT ValidDeathYear CHECK 

REATE TABLE [WORK] 
Work ID Int 

itle 
t 1m C (35 
( cription] Varchar(1000 
ArtistiD Int 
CONSTRAINT \ KEY 
CONSTRAINT Title 
CONSTRAINT ArtistFK FOREIGN KEY(A 

ON DELETE NO ACTION 
ON UPDATE NO ACTION 
CREATE TABLE CUSTOMER ( 
Customer 1D Int 
LastName Char( 25) 
FirstName Char(25) 
Street Char{30) 
City Char(35) 
[State] Char(2) 
ZipPostalCode Char(9) 
Country Char{50) 
AreaCode Char(3) 
PhoneNlumber Char(8) 
Ema] Varchar(100) 
CONSTRAINT CustomerPK 
CONSTRAINT 
}: 


CREATE TABLE TRANS ( 


TransactioniD Int 

DateAqui red Daterime 
AcquisitionPrice Numeric(8,2) 
DateSold Datetime 


Numeric(8,2) 
humeric{(8,2) 


SalesPrice 
AskingPrice 


Customer ID Int 
WorklD Int 
CONSTRAINT TransPK 
CONSTRAINT TransWorkFK 
REFERENCES WORK (WorkId) 
ON UPDATE NO ACTION 
ON DELETE NO ACTION, 
CONSTRAINT TransCustomerfK 


CHECK 

“Canadian”, 
i ‘Spanish’, 
K (DateOfBirth < 
< (DateOfBirth LIKE * [1 
(DateDeceased LIKE [ 


Art 
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‘English’, ‘French’, ‘German', 
KS 
DateDec 


eased), 
29 1L0es 
Ì 27 CO7= BN LOT DID 


NULL IDENTITY (500,1). 
NULL, 


T NULL, 


DEFAULT 


NOT NULL, 


‘Unknown provenance” 


stID) REFERENCES ARTIST (ArtistID) 


NOT NULL IDENTITY (1000,1), 
NOT NULL, 
ROT NULL, 
NULL, 
KULL, 
NULL, 
NULL, 
NULL, 
RULL, 
NULL, 
NULL, 


PRIMARY KEY (CustomeriD), 


EmailAKl UNIQUE (Email) 


KOT NULL IOENTITY (100,1), 
NOT NULL, 

HOT NULL, 

KULL, 

NULL, 

NULL, 

NULL, 

NOT NULL, 


PRIMARY KEY (TransactioniD), 


FOREIGN KEY (Work1D) 


FOREIGN KEY (Customeri0) 


REFERENCES CUSTOMER (Customer1D) 


Figuur 7-11 SQL voor het maken van de tabellen voor View Ridge 


JCO TELERS 
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ON UPDATE NO ACTION 
ON DELETE NO ACTION, 


CONSTRAINT SalesPriceRange CHECK 
((SalesPrice > LOC D (Sa ' 
CON ValialransDate CHE C >m [ 
CREATE TABLE CUSTOMER ARTIST INT 
Artist ID Int 
Customer 1D Int 
CONSTRAINT CAINtPK PRIMARY KEY (ArtistID, CustomerlD) 
CONSTRAINT CAInt_Artist Ft EIGN KEY (ArtistlC 
REFERENCES ARTIST (Artistl 
ON UPDATE HO ACTION 
ON DELETE CASCADE, 
CONSTRALNT REI Y( ! 


REFERENCES 


Figuur 7-11 (vervolg) 


CUSTOMER [TRANS Í [work | ARTIST | 
eV Cato hO== 19 marsen | Cd 9 wek Ol 9 Arun EN 
hare | DsteAcaured Í Tee 
Sveet Í | konvrie Coor N u 
cu Í prowelute Desc orn Í 
Sate | Svefrce ArtsD | | 
Ierortateor | Aörgrce 1 
| carry | Eer CustsrerD rn et — 
| Aestote Í | wad 
| Proretarte 
| Eat en NE: | 
| 
Lm 
| EENES zn | 
| CUSTOMER ARTIST INT | 
| AUD Ee 
gn EET 3 Ce D | 
! 


Figuur 7-12 Het SQL Server-relatiediagram voor de View Ridge-database 


7.4 Het ALTER-statement 


Het ALTER-statement is een SQL DDL-statement waarmee de structuur van een be- 
staande tabel kan worden gewijzigd. Hiermee kun je kolommen toevoegen, verwijde- 
ren of wijzigen. Je kunt met dit statement ook constraints toevoegen en verwijderen. 


7.4.1 Kolommen toevoegen en verwijderen 
Het volgende statement voegt een kolom met de naam MijnKolom aan de tabel CUS- 


TOMER toe: 


ALTER TABLE CUSTOMER ADD MijnKolom Char(5) NULL; 
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Je kunt een bestaande kolom verwijderen met het statement: 
ALTER TABLE CUSTOMER DROP COLUMN MijnKolom; 


Merk de asymmetrie in de syntaxis op — het sleutelwoord COLUMN wordt sa- 
men met DROP gebruikt, maar niet samen met ADD. Zoals je in de volgende 
drie hoofdstukken zult zien, kun je ALTER ook gebruiken voor het wijzigen van 
kolomeigenschappen. 


7.4.2 Constraints toevoegen en verwijderen 
Je kunt als volgt een constraint toevoegen met ALTER: 


ALTER TABLE CUSTOMER ADD CONSTRAINT MijnConstraint CHECK 
([Name] NOT IN (‘Jan Wanbetaler')); 


Merk op dat Name tussen blokhaakjes is gezet om verwarring met het DBMS-sleu- 
telwoord Name te voorkomen. 
Je kunt ALTER ook gebruiken voor het verwijderen van een constraint: 


ALTER TABLE CUSTOMER DROP CONSTRAINT MijnConstraint; 


Opmerking 

Je kunt elke willekeurige SQL-constraint toevoegen of verwijderen met het statement ALTER. Je kunt 
ermee primaire en alternatieve sleutels maken, de nulltoestand instellen en referential integrity 
constraints en data constraints maken. Een andere stijl voor het schrijven van SQL gebruikt CREATE TABLE 
in feite alleen voor het declareren van de kolommen van de tabel - alle constraints worden toegevoegd 
met ALTER. We gebruiken deze stijl niet in dit boek, maar wees je ervan bewust dat deze bestaat. 


7.4.3 Tabellen verwijderen 
Het is heel makkelijk een tabel te verwijderen met SQL. In feite veel te makkelijk. 
Het volgende statement zal de tabel TRANS en alle gegevens daarin verwijderen: 


DROP TABLE [TRANS]; 


Wees heel voorzichtig als je dit statement gebruikt, want het verwijdert de tabel en 
alle gegevens daarin. Pas dit statement niet per ongeluk op de verkeerde tabel toe! 
Het DBMS zal weigeren een tabel te verwijderen die de parent is in een FOREIGN 
KEY-constraint. Het DBMS zal dat zelfs weigeren als er geen children zijn, of als je 
DELETE CASCADE hebt opgegeven. Wil je een dergelijke tabel verwijderen, dan 
zul je in plaats daarvan eerst de foreign key constraint of de child-tabel moeten ver- 
wijderen. Daarna kun je de parent-tabel verwijderen. Zoals je al eerder zag, moeten 
parent-tabellen als eerste worden gemaakt en als laatste worden verwijderd. 
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De volgende statements zijn nodig voor het verwijderen van de tabel CUSTOMER: 


DROP TABLE CUSTOMER ARTIST INT; 
DROP TABLE [TRANS]; 
DROP TABLE CUSTOMER; 


Een andere manier om CUSTOMER te verwijderen is deze: 


ALTER TABLE CUSTOMER ARTIST INT 

DROP CONSTRAINT Customer Artist Int CustomerFk; 
ALTER TABLE [TRANS] 

DROP CONSTRAINT TransCustomerFK; 
DROP TABLE CUSTOMER; 


7.5 SQL DML 


Je weet nu hoe je query’s uitvoert op tabellen met SQL SELECT-statements en hoe je 
tabellen, kolommen en constraints maakt, wijzigt en verwijdert. Je weet echter nog 
niet hoe je SQL gebruikt voor het invoegen, wijzigen en verwijderen van gegevens. 
We zullen deze statements hierna behandelen. 


7.5.1 SQL INSERT met kolomnamen 
Het SQL-commando INSERT heeft een aantal verschillende opties. In de standaard- 


versie noem je de tabel en de kolommen waar je gegevens voor hebt en geeft dan de 
gegevens op in de volgende indeling: 


INSERT INTO ARTIST (LastName, FirstName, Nationality, 
DateOf Birth, DateDeceased) 
VALUES ('Miro', ‘Joan’, ‘Spanish’, 1893, 1983); 


Merk op dat de kolomnamen en de waarden beide tussen haakjes staan. Je kunt de 
lijst met kolomnamen weglaten, mits je gegevens voor alle kolommen levert, deze 


gegevens in dezelfde volgorde staan als de kolommen in de tabel en je geen surro- 
gaatsleutels hebt. 


INSERT INTO ARTIST 
VALUES ('Miro', ‘Joan’, ‘Spanish’, 1893, 1983); 


Je hoeft de waarden niet in dezelfde volgorde te leveren als de kolommen in de ta- 
bel. Wil je Nationality om de een of andere reden vóór Name leveren, dan kun je de 
namen van de kolommen en de gegevenswaarden omdraaien, zoals je dat in het vol- 
gende voorbeeld ziet: 
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INSERT INTO ARTIST (Nationality, LastName, FirstName, 
DateDeceased, DateOfBirth) 
VALUES ('Spanish', 'Miro', ‘Joan', 1893, 1983); 


Heb je niet alle gegevens, dan geef je gewoon de namen op van de kolommen waar- 
voor je wel gegevens hebt. Schrijf bijvoorbeeld het volgende als je alleen LastName, 
FirstName en Nationality hebt: 


INSERT INTO ARTIST (LastName, FirstName, Nationality) 
VALUES ('Miro', ‘Joan’, 'Spanish'); 


Je moet natuurlijk waarden hebben voor alle kolommen die NOT NULL zijn. 


7.5.2 Grootschalig invoegen met INSERT 

Een van de meest gebruikte vormen van INSERT maakt gebruik van een SQL 
SELECT-statement voor het leveren van waarden. Stel dat je een tabel met de naam 
IMPORTED_ARTIST hebt, met de namen, nationaliteiten en geboortedatums van 
een aantal kunstenaars. Je kunt deze gegevens in dat geval aan de tabel ARTIST toe- 
voegen met het volgende statement: 


INSERT INTO ARTIST (LastName, FirstName, Nationality, 
DateOf Birth) 

SELECT LastName, FirstName, Nationality, Date0OfBirth 

FROM IMPORTED ARTIST; 


Merk op dat het sleutelwoord VALUES niet wordt gebruikt bij deze vorm van 
invoegen. 

Deze syntaxis zou je bekend moeten voorkomen. We gebruikten deze in de voor- 
beelden voor het normaliseren en denormaliseren in hoofdstuk 3 en 4. 


7.5.3 Het UPDATE-commando 

Het SQL-commando UPDATE wijzigt de waarden van bestaande rijen. Het volgen- 
de statement verandert de waarde van City in ‘New York City’ voor de klant met de 
CustomerID rooo: 


UPDATE CUSTOMER 


SET City = 'New York City' 
WHERE CustomerID = 1000; 
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Schrijf het volgende SQL-statement als je de waarde van City en de waarde van State 
wilt veranderen: 


UPDATE CUSTOMER 
SET City = ‘New York City’, State = 'NY' 
WHERE CustomerID = 1000; 


Het DBMS zal alle referential integrity constraints afdwingen tijdens het verwerken 
van UPDATE-commando's. Alle sleutels van de database van View Ridge zijn sur- 
rogaatsleutels, maar het DBMS zal updates cascading doorgeven of weigeren (NO 
ACTION), overeenkomstig de specificaties in de FOREIGN KEY-constraints, voor 
tabellen met data keys. Het DBMS zal bovendien de referential integrity constraint 
voor het bijwerken van een externe sleutel afdwingen als er een FOREIGN KEY- 
constraint is. 


7.5.4 Grootschalige updates 


Er zijn heel makkelijk grootschalige updates uit te voeren met het SQL-commando 
UPDATE. Dat is in feite zo makkelijk dat het gevaarlijk kan zijn. Het statement: 


UPDATE CUSTOMER 
SET City = ‘New York City’; 


zal de waarde van City veranderen voor elke rij van de tabel CUSTOMER. We zou- 
den helemaal niet blij zijn met het resultaat als we alleen de waarde voor klant num- 
mer 1000 wilden veranderen — elke klant zou nu de waarde ‘New York City’ hebben. 
Je kunt grootschalige updates uitvoeren met een WHERE-clausule die meer rijen 
zoekt. We schrijven bijvoorbeeld het volgende als we de AreaCode willen veranderen 
voor alle klanten die in Denver wonen: 


UPDATE CUSTOMER 
SET AreaCode = '303' 
WHERE City = 'Denver'; 


7.5.5 Bijwerken met waarden uit andere tabellen 
Het UPDATE-commando kan de waarde van een kolom gelijkmaken aan de waarde 
van een kolom uit een andere tabel. De View Ridge-database heeft geen passend 
voorbeeld voor deze bewerking. Stel dus dat we in plaats daarvan een tabel met de 
naam BELASTING-TABEL hebben met de kolommen (Belasting, Plaats), waarbij 
Belasting de gemeentelijke belasting aangeeft voor de Plaats. 

Stel nu dat we een tabel met de naam BESTELBON hebben, die de kolommen 
Belastingtarief en Plaats omvat. We kunnen alle rijen voor bestellingen uit de stad 
Bodega Bay bijwerken met het volgende SQL-statementt: 


UPDATE BESTELBON 
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SET Belastingtarief = 

(SELECT Belasting from BELASTING TABEL 

WHERE BELASTING TABEL.Plaats =— 'Bodega Bay') 
WHERE BESTELBON.Plaats = ‘Bodega Bay'; 


Het is waarschijnlijker dat we de waarde van het belastingtarief voor een bestelbon 
willen bijwerken zonder expliciet een plaats op te geven. Stel dat we Belastingtarief 
willen bijwerken voor bestelbon nummer rooo. We gebruiken in dat geval het vol- 
gende SQL-statement: 


UPDATE BESTELBON 

SET Belastingtarief = 

(SELECT Belasting from BELASTING TABEL 

WHERE BELASTING TABEL.Plaats = BESTELBON.Plaats) 
WHERE BESTELBON. Nummer = 1000; 


SQL SELECT-statements zijn op allerlei verschillende manieren met UPDATE-state- 
ments te combineren. We moeten nu doorgaan naar andere onderwerpen, maar pro- 
beer deze en andere varianten van UPDATE zelf eens uit. 


7.5.6 Het DELETE-commando 

Het DELETE-commando kunnen we gebruiken om één of meerdere records te 
verwijderen. Het volgende SQL-statement verwijdert de rij van een klant met de 
CustomerID rooo: 


DELETE FROM CUSTOMER 
WHERE CustomerID = 1000; 


Je verwijdert natuurlijk alle klantenrijen als je de WHERE-clausule weglaat. Je moet 
dus ook weer voorzichtig zijn met deze opdracht. 

Het DBMS zal alle referential integrity constraints afdwingen tijdens het ver- 
werken van DELETE-commando's. Je zult bijvoorbeeld niet in staat zijn een CUS- 
TOMER-rij uit de View Ridge-database te verwijderen als deze rij een of meer 
TRANS-children heeft. Wordt er een rij zonder TRANS-children verwijderd, dan zul- 
len bovendien alle CUSTOMER-_ARTIST_INT-children die er eventueel bestaan ook 
worden verwijderd. Deze actie wordt uitgevoerd omdat CASCADE DELETE is opge- 
geven voor de relatie tussen CUSTOMER en CUSTOMER _ARTIST_INT. 


7.6 Nieuwe vormen van join 


Je hebt in hoofdstuk 2 geleerd hoe je joins uitvoert. We zetten deze toelichting hier 
voort en laten je een andere join-syntaxis zien. We bespreken ook manieren voor het 
verwerken van joins op tabellen die nullwaarden bevatten. 
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7.6.1 Voorbeeldgegevens voor View Ridge | 
We gebruiken in de rest van het boek de voorbeeldgegevens voor View Ridge die je | 
in Figuur 7-13 ziet. | 


Street State [ ZipPostalCode | 
[soor |smm ome | 813 Tumbleweed Lane | Durango 

Tiffany 88 1st Avenue 
en [rammen jason Jom |oo 
1036 Selma 205 Burnaby BC V6Z 1W2 


Renton 


WA 
A 


Vancouver 


105 Locust Ave GA 30322 


94923 


20003 


Figuur 7-13 Voorbeeldgegevens voor View Ridge 


een paneel 
eer jn [ee | soe [pamommnermen | 
EEEN 
ECCE 
CEN CEN EN 
ECCE 
ENNE 
EN CNCNCNENEN 


(a) Voorbeeldgegevens voor CUSTOMER 


David Smith@somewhere.com 


Tiffany. Twilight@somewhere.com 


Fred.Smathers@somewhere com 


MaryBeth.Frederickson@somewhere.com 


Selma.Warning@somewhere com 


Susan.Wu@somewhere.com 


Donald.Gray@somewhere.com 


Chris. Wilkens@somewhere.com 
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LastName FirstName Nationality 


DateOfBirth 
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1 Miro Joan Spanish 1893 

2 Kandinsky Wassily Russian | 1866 
A | 

3 Klee Paul German 


4 Matisse French 
Faes ET 
5 Chagall Marc French 


Sargent John Singer United States 


17 Tobey Mark United States 
18 Horiuchi Paul United States 
19 Graves Morns United States 


(b) ARTIST Table Data 


ArtistiD CustomerlD ArtistD CustomerlD 
1 1001 
1 1034 
ala al 
2 1001 
2 1034 
4 1001 


(c) Voorbeeldgegevens voor CUSTOMER ARTIST_INT 


Figuur 7-13 (vervolg) 
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TransactionlD | DateAcquired | AcquisitionPrice | AskingPrice | DateSoldiD | SalesPrice | CustomerlD 


100 11/4/2005 $30,000.00 | S45,000.00 | 12/14/2005 | S42,500.00 1000 


11/7/2005 $250.00 S500.00 12/19/2005 | S500.00 1015 
Te 102 11/17/2005 S125.00 S250.00 1/18/2006 | $200.00 1001 


11/17/2005 S250.00 S500.00 | 12/12/2006 S400.00 | 1034 522 


11/17/2005 S250.00 S250.00| 1/1 8/2006 | $200.00 1001 523 


105 11/17/2005 $200.00 S500.00 | 12/12/2006 S400.00 1034 524 


3/3/2006 $1,500.00 | $3,000.00| 6/7/2006| $2,750.00| 1033 537 
|__121 | _ or212006 $15,000.00 | S30,000.00 | 11/28/2006 | $27,500.00| 1015 548 


125 11/21/2006 S$125.00 $250.00 [| 12/18/2006 EE 00 1001 551 ë 


$200.00 | __s400.00 ss2 | 
127 8125.00 | _ $500.00| 12/22/2006 | _s400.00| 1034 

128 s125.00 | _ s250.00 an6a0o7 | _s22500 1036 | 554 
s250 00 |_ano2007 s225.00| 1036 555 | 
151 $10,000.00 | s20,000.00 | e/28/2007 


$17,500.00 1036 561 


152 5/18/2007 S125.00 S250.00 | 8/15/2007 S225.00 1001 | 562 


|__153 | _sne/zoor) s200.00 | s4oooo| 8/15/2007| s350ool 1001 | 563 | 

$250.00 | _ $500.00| 9/28/2007| saoo.ool 1040 564 | 

s250.00 | 500.00 565 
156 $250.00 RTT 8400.00 | 1040 566 


an 
kes 
D 


ana 
© lo 
Ee | 


161 $7,500.00 
171 $35,000.00 
175 $40,000.00 
$2,000.00 
$2,000.00 


EE EE 


$200.00 


$15,000.00 | 9/29/2007 | $13,750.00 1033 570 
—= — 

$60,000.00 | 9/29/2007 | $55,000.00 | 1000 571 

$75,000.00 | 12/18/2007 | $72,500.00 1036 500 


$500.00 578 
4/26/2008 


$3,500.00 $3,250.00 1040 580 | 
$3,500.00 | _4/26/2008 | $3,250.00 1040 581 

aen Tr ee 

$250.00 | 9/27/2008 | _$225.00 1051 585 

$400.00 

$500.00 | 9/27/2008 | _$475.00 1051 587 


$500.00 588 


$500.00 589 
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Figuur 7-13 (vervolg) 
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7.6.2 De JOIN ON-syntaxis 


Je leerde in hoofdstuk 2 joins te schrijven met de volgende syntaxis: 


SERBCT, 
FROM ARTIST, WORK 
WHERE ARTIST.ArtistID = WORK.ArtistID; 


Een andere manier waarop je dezelfde join kunt schrijven is: 


SELECIP SS 
FROM ARTIST JOIN WORK 
ON ARTIST.ArtistID = WORK.ArtistID; 


Deze twee joins zijn identiek. De tweede versie is volgens sommige mensen makke- 
lijker te begrijpen dan de eerste. 

Je kunt deze alternatieve versie ook gebruiken voor joins met drie of meer tabel- 
len. Schrijf bijvoorbeeld het volgende als je een lijst wilt ophalen met de namen van 
klanten en de namen van de kunstenaars in wie deze klanten geïnteresseerd zijn: 


SELECT CUSTOMER.Name, ARTIST.Name 
FROM CUSTOMER JOIN CUSTOMER ARTIST _INT 
ON CUSTOMER. CustomerID = CUSTOMER ARTIST_INT.CustomerID 
JOIN ARTIST 
ON CUSTOMER ARTIST _INT.ArtistID = ARTIST.ArtistID; 


Je kunt dat statement zelfs nog eenvoudiger maken door tabelaliassen te gebruiken: 


SELECT C.LastName, C.FirstName, A.LastName AS ArtistName 
FROM CUSTOMER AS C JOIN CUSTOMER ARTIST_INT AS CI 
ON C.CustomerID = CI.CustomeriD 


JOIN ARTIST AS A 
ON CI.ArtistID = A.ArtistID 
ORDER BY C.LastName, C.FirstName; 


Het resultaat van dit statement is te zien in Figuur 7-14. 
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LastName 


Frederickson 
Frederickson 


W VO NDE WN 


10 


First Name 
_Ì Mary Beth 
“Mary Beth 
Mary Beth 
Mary Beth 
Donald 
Donald 
Donald 
Jeffrey 
Jeffrey 
Jeffrey 


ArtistName 
Chagall 
Kandinsky 
Matisse 
Miro 
Graves 
Horiuchi 
Tobey 
Graves 
Horiuchi 

Tobey 


Figuur 7-14 Resultaat met tabelaliassen 


7.6.3 Outer j 


oins 


De volgende join zal de tabel van Figuur 7-15 opleveren: 


SELECT 


FROM 
ON 
ORDER BY 


C.LastName, C.FirstName, T.TransactionID, 
T.SalesPrice 


CUSTOMER AS C JOIN TRANS T 
C.CustomerID = T.CustomerID 


T.Transact 


ionID; 


Dit resultaat klopt maar laat acht van de tien rijen uit de tabel CUSTOMER zien. Wat 
is er met de andere twee klanten gebeurd? 


Kijk eens goed naar de gegevens in Figuur 7-13 en je zult zien dat alle niet-getoonde 
klanten mensen zijn die nooit iets van de galerie hebben gekocht. De primaire sleu- 
telwaarde van deze drie klanten komt niet overeen met welke foreign key in de tabel 
TRANS dan ook. Ze verschijnen niet in het resultaat van deze join omdat ze geen 


overeenkomst h 


ebben. 


We kunnen wel alle rijen van CUSTOMER laten verschijnen door een zogenaam:- 


de outer join te gebruiken. De syntaxis daarvan is als volgt (het enige verschil met de 
vorige join is het woord LEFT): 


SELECT 
FROM 


ON 
ORDER BY 
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C.LastName 


‚ C.FirstName, T.TransactionID, 


T.SalesPrice 

CUSTOMER AS C LEFT JOIN TRANS T 
C.CustomerID = T.CustomerID 
T.TransactionID; 


SQL VOOR HET MAKEN VAN DATABASES 


LastName FirstName _ TransactionlD _SalesPrice 
1 Janes ee Jeffrey 100 42500.00 
2 Twiidht Tiffany 101 500.00 
3 Smith David 102 200.00 
4 Frederickson Mary Beth 103 400.00 
5 Smith David 104 200.00 
6 Frederickson Mary Beth 105 400.00 
7 Smathers Fred 115 2750.00 
8 Twilight Tiffany 121 27500.00 
5 Smith David 125 200.00 
10 _Frederickson Mary Beth 127 400.00 
1 Waming Selma 128 225.00 
12 __Wamina Selma 123 225.00 
13 __Wamina Selma 151 17500.00 
14 _Smith David 152 225.00 
15 Smith David 153 350.00 
16 Gray Donald 154 400 00 
17 __ Gray Donald 156 400.00 
18 __Smathers Fred 161 13750.00 
13 _ Janes Jeffrey 171 55000.00 
20 __Waming Selma 175 72500.00 
21 Gray Donald 201 3250.00 
22 Gray Donald 202 3250.00 
23 _ Wilkens Chris 225 225.00 
24 _ Wilkens Chris 227 475.00 
25 _ Twilight Tiffany 241 4750.00 


Figuur 7-15 Het resultaat van een join van CUSTOMER en TRANS 


Je ziet het resultaat in Figuur 7-16. Merk op dat de waarde van SalesPrice NULL is 
voor alle klanten die geen aankopen hebben gedaan (Susan Wu en Lynda Johnson). 


Outer joins kunnen vanaf de linker- of de rechterkant worden uitgevoerd. Wordt de 
outer join vanaf links uitgevoerd, dan zullen alle rijen van de tabel aan de linkerkant 
(de eerste tabel in de join) in het resultaat worden opgenomen. Wordt de outer join 
vanaf rechts uitgevoerd, dan worden alle rijen van de tabel aan de rechterkant (de 
tweede tabel in het joinstatement) in het resultaat opgenomen. 

Als illustratie van een rechter join gebruiken we het vorige SQL-statement met 
een kleine aanpassing (LEFT is vervangen door RIGHT): 
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LastName FirstName _TransactionlD SalesPrice 
1 ÌWu  ÌÈ Susan NUL NULL 
2 “Johnson Lynda NULL NULL 
3 Janes Jeffrey 100 42500.00 
4 Twilight Tiffany 101 500.00 
5 Smith David 102 200.00 
6 Frederickson Mary Beth 103 400.00 
7 Smith David 104 200.00 
8 Frederickson MaryBeth 105 400.00 
9 Smathers Fred 115 2750.00 
10 _ Twilight Tiffany 121 27500.00 
11 Smith David 125 200.00 
12 _Frederickson Mary Beth 127 400.00 
13 _ Waming Selma 128 225.00 
14 __Waming Selma 129 225.00 
Í 15 _Waming Selma 151 17500.00 
16 Smith David 152 225.00 
| 17 _Smith David 153 350.00 
18 Gray Donald 154 400.00 
19 Gray Donald 156 400.00 
20 _Smathers Fred 161 13750.00 
21 Janes Jeffrey 171 55000.00 
22 Waming Selma 175 72500.00 
23 Gray Donald 201 3250.00 
24 Gray Donald 202 3250.00 
25 Wilkens Chris 225 225.00 
26 Wilkens Chris 227 475.00 


Twilight 


4750.00 


Figuur 7-16 Het resultaat van een LEFT OUTER-join 


SELECT C.LastName, C.FirstName, T.TransactionID, 
T.SalesPrice 
FROM CUSTOMER AS C RIGHT JOIN TRANS T 
ON C.CustomerID = T.CustomerID 
ORDER BY T.TransactionID; 


Met de linker join lieten de nullwaarden klanten zien die geen werk hadden aange- 
schaft. Met de rechter join laten de nullwaarden werk zien dat niet door klanten is 
gekocht (en dus nog te koop is). Het resultaat van de rechter join zie je in Figuur 7-17. 
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Ie LastName FirstName _ TransactionlD SalesPrice 
1 {Janes | Jeffrey 100 42500.00 
2 Twilidht Tiffany 101 500.00 

13 Smith David 102 200.00 
4 Frederickson Mary Beth 103 400.00 
5 Smith David 104 200.00 

| 6 Frederickson Mary Beth 105 400.00 

|7__Smathers Fred 115 2750.00 
8 Twilight Tiffany 121 27500.00 
3 Smith David 125 200.00 

[10 NULL NULL 126 NULL 
1 Frederickson Mary Beth 127 400.00 
12 _ Waming Selma 128 225.00 
13 __ Waming Selma 129 225.00 
£ _Waming Selma 151 17500.00 
15 _ Smith David 152 225.00 

[16 Smith David 153 350.00 

[17 _ Grey Donald 154 400.00 
18 _ NULL NULL 155 NULL 

[13 Grey Donald 156 400.00 
20 _Smathers Fred 161 13750.00 
21 _ Janes Jeffrey 171 55000.00 

|22 _Waming Selma 175 72500.00 

[23 _ NULL NULL 181 NULL 
4 Gray Donald 201 3250.00 
25 Gray Donald 202 3250.00 
26 _ Wilkens Chris 225 225.00 
27 NULL NULL 226 NULL 

(28 Wilkens Chris 227 475.00 
23 NULL NULL 228 NULL 
30 NULL NULL 229 NULL 
31 Twilight Tiffany 241 4750.00 
32 NULL NULL 251 NULL 
33 NULL NULL 252 NULL 
34 NULL NULL 253 NULL 


NULL 


NULL 


NULL 


Figuur 7-17 Resultaat van rechter join van CUSTOMER en TRANS 


SQL VOOR HET MAKEN VAN DATABASES 


Joins die geen outer joins zijn, heten inner joins. Alle joins die we voor deze para- 
graaf hebben gezien waren inner joins, hoewel we die term niet hebben gebruikt. 
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Outer joins zijn, net als inner joins, tot op elk gewenst niveau te combineren. Het 
volgende SQL-statement zal een lijst ophalen met alle klanten en de kunstenaars in 
wie deze klanten geïnteresseerd zijn: 


SELECT C.LastName, FirstName Customer, A.LastName AS 
ArtistName 
FROM CUSTOMER AS C LEFT JOIN CUSTOMER ARTIST INT AS CI 
ON C.CustomerID = CI.CustomerID 
LEFT JOIN ARTIST AS A 
ON CI.ArtistID = A.ArtistID; 


LastName 


FirstName _ ArtistName 


3 Janes Jeffrey Graves 

4 Smith David Miro 

5 Smith David Kandinsky 
6 Smith David Matisse 
7 Smith David Chagall 
8 Smith David Sargent 
9 Twilight Tiffany Sargent 
10 _ Twilight Tiffany Tobey 
11 __ Twilight Tiffany Horiuchi 
12 _ Twilight Tiffany Graves 
13 _Smathers Fred Tobey 
14 _Smathers Fred Horiuchi 
15 _Smathers Fred Graves 


16 _Frederickson Mary Beth Miro 
17 _Frederickson Mary Beth Kandinsky 
18 _Frederickson MaryBeth Matisse 
19 _Frederickson MaryBeth Chagall 
20 _Waming Selma Chagall 

21 __Waming Selma Sargent 
22 _Waming Selma Graves 
23 Wu Susan NULL 

24 Gray Donald Tobey 

25 Gray Donald Horiuchi 
26 Gray Donald Graves 
27 _ Johnson Lynda NULL 

28 Wilkens Chris Tobey 

29 Wilkens Chris Horiuchi 
Graves 


Figuur 7-18 Het resultaat van geneste LEFT OUTER-joins 
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Je ziet het resultaat in Figuur 7-18. Als je een van beide LEFTs uit de expressie weg- 
laat, duiken de nullrijen niet op. 


7.7 _SQLl-views gebruiken 


Een SQL-view is een virtuele tabel die is samengesteld op basis van andere tabellen 
of views. Een view bevat zelf geen gegevens, maar haalt gegevens uit tabellen of an- 
dere views. Views worden gemaakt met behulp van een CREATE VIEW-statement 
waarin je een SELECT-statement gebruikt — de enige beperking die aan dergelijke 
statements wordt opgelegd is dat ze geen ORDER BY-clausule mogen bevatten. De 
sorteervolgorde wordt geleverd door het SELECT-statement dat de view verwerkt. 


Opmerking 

Views zijn populaire standaardconstructies van SQL-92. Access ondersteunt ze echter niet. je kunt in Access 
in plaats daarvan een query maken, daar een naam aan geven en deze dan opslaan. Je kunt de query 
dan op dezelfde manieren verwerken als we views zullen verwerken in de volgende toelichting. 

SQL Server, Oracle en DB2 ondersteunen allemaal views. Views zijn belangrijke structuren die op veel 
manieren zijn te gebruiken. Maak niet de vergissing op basis van de ontbrekende ondersteuning in Access 
te concluderen dat views niet belangrijk zijn. Lees verder en gebruik zo mogelijk SQL Server of Oracle voor 
het verwerken van de statements in dit deel. 


Het volgende statement definieert een view met de naam CustomerNameView op 
de tabel CUSTOMER: 


CREATE VIEW CustomerNameView AS 


SBEBGT: LastName AS CustomerLastName, 
FirstName AS CustomerFirstName 
FROM CUSTOMER; 


Bedenk dat het resultaat van een statement als dit alleen bestaat uit een systeem- 
boodschap die zegt dat de opdracht is beëindigd. Met een hulpmiddel als SQL Server 
Management Studio zal ook het betreffende view-object gemaakt worden. 

Is de view eenmaal gemaakt, dan kan deze op precies dezelfde manier als een 
tabel in de FROM-clausule van SELECT-statements worden gebruikt. Het volgende 
statement haalt een lijst op van de namen van klanten, in gesorteerde volgorde: 


SELECT ei 
FROM CustomerNameView 
ORDER BY CustomerlLastName, CustomerFirstName; 


1_ Deze beperking is onderdeel van de standaard SQL-92. De feitelijke implementatie verschilt per 
DBMS. Oracle staat views toe die ORDER BY bevatten, terwijl SQL Server dat in beperkte mate doet. 
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Je ziet het resultaat met de voorbeeldgegevens uit paragraaf 7.6.r in Figuur 7-19. 
Merk op dat het aantal geleverde kolommen afhankelijk is van het aantal kolommen 
in de view en niet van het aantal kolommen in de onderliggende tabel. SELECT * 
levert maar twee kolommen in dit voorbeeld, omdat de view maar twee kolommen 


heeft. 
__CustomerLastName _ CustomerfFirstName 
1 Mary Beth 
2 Gray Donald 
3 Janes Jeffrey 
4 Johnson Lynda 
5 Smathers Fred 
6 Smith David 
7 Twilight Tiffany 
8 Waming Selma 
9 Wilkens Chris 
10 Wu Susan 


Figuur 7-19 Het resultaat van CustomerNameView 


Merk ook op dat de namen van de kolommen LastName en FirstName uit de tabel 
CUSTOMER in de view gewijzigd zijn in CustomerLastName en Customer FirstNa- 
me. Daarom gebruikt het ORDER BY-gedeelte in het SELECT-statement Customer- 
FirstName en CustomerLastName. 

Figuur 7-20 geeft een opsomming van het nut van views. Ze kunnen kolommen 
of rijen verbergen. Ze kunnen ook worden gebruikt voor het weergeven van de resul- 
taten van berekende kolommen, voor het verbergen van ingewikkelde SQL-syntaxis 
en voor het gelaagd gebruiken van ingebouwde functies voor het leveren van resulta- 
ten die niet met een enkel SQL-statement zijn te produceren. 


Het nut van views: 
* verbergen van kolommen of rijen; 

* weergeven van resultaten van berekeningen; | 
* verbergen van ingewikkelde SQL-syntaxis; | 
* gelaagd gebruiken van ingebouwde functies; 

» leveren van een isolatieniveau tussen tabelgegevens en de gegevens die de gebruikers te zien krijgen; 
« toekennen van verschillende verwerkingspermissies aan verschillende views op dezelfde tabel; 

+ toekennen van verschillende triggers aan verschillende views op dezelfde tabel. | 


Figuur 7-20 Het nut van views 


Views kunnen verder aliassen leveren voor tabelnamen en de echte tabelnamen 
daarmee verbergen voor applicaties en gebruikers. Views worden ook gebruikt om 
verschillende verwerkingspermissies en triggers aan diverse views op dezelfde tabel 
toe te kennen. We zullen voorbeelden laten zien voor elk van deze doeleinden. 
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7.7.1 Views gebruiken voor het verbergen van kolommen en rijen 
Views kun je gebruiken om kolommen te verbergen, om de resultaten te vereen- 
voudigen, of om te voorkomen dat gevoelige gegevens worden weergegeven. Neem 
bijvoorbeeld aan dat de gebruikers bij View Ridge een vereenvoudigde klantenlijst 
willen zien, die alleen namen en telefoonnummers toont. Het volgende statement 
definieert een view met de naam BasicCustomerData die deze lijst zal leveren: 


CREATE VIEW BasicCustomerDataView AS 
SELECT. LastName AS CustomerLastName, 
FirstName AS CustomerFirstName, 
AreaCode, PhoneNumber 
FROM CUSTOMER; 


Deze view kun je bijvoorbeeld gebruiken met het volgende SQL-statement. 
SELECT 
FROM BasicCustomerDataView 


ORDER BY CustomerLastName, CustomerFirstName; 


Het resultaat staat in Figuur 7-21. 


CustomerlastName _ CustomerFirstName _AreaCode PhoneNumber 
1 iFrederckson __ : Mary Beth 303 513-8822 
5 rr EN an ES 
3 Janes Jeffrey 425 543-2345 
4 Johnson Lynda 202 438-5498 
5 Smathers Fred 206 876-9911 
6 Smith David 970 654-9876 
7 Twilight Tiffany 360 765-5566 
8 Waming Selma 604 9388-0512 
6] Wilkens Chris 360 876-8822 
10 __ Wu Susan 404 653-3465 


Figuur 7-21 Het resultaat van BasicCustomerDataView 


Een soortgelijke techniek kan worden gebruikt voor het verbergen van kolommen, 
zoals AcquisitionPrice of SalesPrice in TRANS, in gevallen waarin geen gevoelige 
gegevens mogen worden weergegeven. 

Er kunnen ook rijen worden verborgen in een view met behulp van een WHERE- 
clausule. Het volgende SQL-statement definieert een view met de klantnaam en de 
telefoongegevens voor alle klanten met een adres in de staat Washington (WA): 
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CREATE VIEW BasicCustomerDataWAView AS 
SELECT LastName AS CustomerLastName, 
FirstName AS CustomerFirstName, 
AreaCode, PhoneNumber 
FROM CUSTOMER 
WHERE State = 'WA'; 


Deze view kun je op de volgende manier gebruiken: 


SELECT * 
FROM BasicCustomerDataWAView 
ORDER BY CustomerLastName, CustomerFirstName; 


Het resultaat staat in Figuur 7-22. 


CustomerLastName 


CustomerFirstName _AreaCode PhoneNumber 


L (Janes } vefrey 425 5343-2345 
2 Smathers Fred 206 876-991 
3 Twilight Tiffany 360 765-5566 
4 Wilkens 


360 876-8822 


Figuur 7-22 Het resultaat van BasicCustomerDataWAView 


Zoals gewenst worden alleen klanten in deze view weergegeven die in de staat 
Washington wonen. Dat valt niet meteen op, omdat State geen deel uitmaakt van de 
resultaten van de view. Dat kan een goede of een slechte eigenschap zijn, afhanke- 
lijk van waar de view voor wordt gebruikt. Het is een goede eigenschap als deze view 
wordt gebruikt in een context waarin alleen klanten uit Washington een rol spelen. 


Het is een slechte eigenschap als de view de indruk wekt dat dit de enige klanten zijn 
van galerie View Ridge. 


7.7.2 Views voor de resultaten van berekende kolommen 

Views zijn ook te gebruiken voor het weergeven van de resultaten van berekeningen, 
zonder dat de gebruiker uitdrukkingen voor het berekenen hoeft in te voeren. De vol- 
gende view combineert bijvoorbeeld de kolommen AreaCode en PhoneNumber en 
geeft het resultaat een passende opmaak: 


CREATE VIEW CustomerPhoneView AS 
SELECT LastName AS CustomerLastName, 
FirstName AS CustomerFirstName, 
('(* + AreaClode + ') ' + PhoneNumber) As 
CustomerPhone 
FROM CUSTOMER; 
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Als de gebruiker het volgende invoert, wordt het resultaat weergegeven dat je in 
Figuur 7-23 ziet: 


SELECT * 
FROM CustomerPhoneView 
ORDER BY CustomerlLastName, CustomerFirstName; 


CustomerlastName CustomerFirstName __CustomerPhone 

[1 È Frederickson __ ° Mary Beth (303) 513-8822 
2 Gray Donald (707) 568-4839 
13 Janes Jeffrey (425) 543-2345 
4 Johnson Lynda (202) 438-5498 
5 Smathers Fred (206) 876-9911 
6 Smith David (970) 654-9876 
7 Twilight Tiffany (360) 765-5566 
8 Wamina Selma (604) 9388-0512 
[3 Wilkens Chris (360) 8376-8822 
10 Wu Susan (404) 653-3465 


Figuur 7-23 Het resultaat van CustomerPhoneView 


Het opnemen van berekeningen in views heeft twee grote voordelen: ten eerste hoe- 
ven de gebruikers van de view geen uitdrukking te schrijven om de resultaten te 
krijgen die ze willen zien (en ze hoeven ook niet te weten hoe ze dat zouden moeten 
doen). Het garandeert bovendien consequente resultaten. Zou elke ontwikkelaar die 
een berekening gebruikt zijn of haar eigen SQL schrijven, dan bestaat de kans dat ze 
de berekening anders schrijven, wat tot inconsequente resultaten kan leiden. 


7.7.3 Views gebruiken voor het verbergen van SQL-syntaxis 

Een ander doel van views is het verbergen van SQL-syntaxis. Dat wordt gedaan om 
ontwikkelaars de moeite te besparen telkens een ingewikkeld statement te moeten 
invoeren als ze een bepaalde weergave willen zien, of om de voordelen van ingewik- 
kelde SQL-statements beschikbaar te stellen voor ontwikkelaars die geen SQL ken- 
nen. Dit gebruik van views garandeert ook weer consequente resultaten, net als het 
gebruik van views voor berekeningen. 

Twee dingen waar views vaak voor worden gebruikt, zijn het verbergen van 
joins en het verbergen van subquery’s. Stel bijvoorbeeld dat de verkopers van View 
Ridge willen weten welke klanten in welke kunstenaars zijn geïnteresseerd. Om 
deze interesses weer te geven, zijn twee joins nodig: een voor het samenvoegen van 


2 Het plusteken (+) moet in Oracle worden vervangen door twee verticale strepen (||) voor het samen- 
voegen van strings. 


267 


DEEL 3 | DATABASES IMPLEMENTEREN 


CUSTOMER en CUSTOMER ARTIST_INT en een voor het samenvoegen van dat 


resultaat met ARTIST. Het volgende SQL-statement definieert een view die deze 
joins opzet: 


CREATE VIEW CustomerInterestsView AS 
SELECT C.LastName AS CustomerLastName, 
C.FirstName AS CustomerFirstName, 
A.LastName AS ArtistName 
FROM CUSTOMER AS C JOIN CUSTOMER ARTIST INT CI 
ON C.CustomerID = CI.CustomerID 
JOIN ARTIST AS A 
ON CI.ArtistID = A.ArtistID; 


Merk op dat de aliassen CustomerLastName en ArtistName voor C.LastName en 
A.LastName worden gebruikt. Deze kolomaliassen zijn niet optioneel — de resul- 
terende tabel zou twee kolommen met de naam LastName hebben als we ze niet 
zouden gebruiken. Het DBMS zou de ene LastName niet van de andere kunnen 
onderscheiden en zou een foutmelding geven als je probeert een dergelijke view te 
maken. 

Er moet wat werk worden gedaan om dit ingewikkelde SQL-statement te schrij: 
ven, maar het resultaat van dit statement kan met een eenvoudig SELECT-statement 


worden verkregen zodra de view eenmaal gemaakt is. Het volgende statement geeft 
de resultaten bijvoorbeeld weer gesorteerd op Customer: 


SELECT À 


FROM CustomerInterestsView 
ORDER BY Customer; 


Je ziet het nogal omvangrijke resultaat in Figuur 7-24. Het is duidelijk dat het veel 
eenvoudiger is de view te gebruiken dan de joïinsyntaxis op te stellen. Zelfs ontwik- 


kelaars die goed bekend zijn met SQL zullen het waarderen als ze een eenvoudiger 
view hebben waar ze mee kunnen werken. 


7.1.4 Gelaagd gebruiken van ingebouwde functies 

Je zult je uit hoofdstuk 2 herinneren dat je geen berekeningen of ingebouwde func- 
ties kunt gebruiken als een onderdeel van een WHERE-clausule. Je kunt echter wel 
een view maken die de waarde van een variabele berekent en dan SQL voor deze view 
schrijven die de berekende variabele in een WHERE-clausule gebruikt. Kijk eens 
naar de volgende view-definitie om te begrijpen hoe dat in elkaar zit: 
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CREATE VIEW ArtistWorkNetView AS 
LastName AS ArtistLastName 


SELECT W.WorkID, 
FirstName AS ArtistFirstName, Title, Copy, 
DateSold, AcquisitionPrice, SalesPrice, 
(SalesPrice - AcquisitionPrice) AS NetProfit 

FROM TRANS AS T JOIN WORK AS W 
ON T.WorkID = W.WorkID 


JOIN ARTIST AS A 
ON W.ArtistID = A.ArtistID; 


vg _CustomerLast Name _ CustomerFirstName _ ArtistName Ì 

Ee t Mary Beth DE 

2 Frederickson Mary Beth Kandinsky 

3 Frederickson Mary Beth Miro 

4 Frederickson Mary Beth Matisse 

5 Gray Donald Tobey 

6 Gray Donald Horiuchi 

7 Gray Donald Graves 

8 Janes Jeffrey Graves 

5, Janes Jeffrey Horiuchi 

10 Janes Jeffrey Tobey 

u Smathers Fred Tobey 

12 _Smathers Fred Horiuchi 

13 _Smathers Fred Graves 

14 Smith David Chagall 

15 _ Smith David Matisse 

16 Smith David Kandinsky 

17 __Smith David Miro 

18 __ Smith David Sargent 

139 _ Twilight Tiffany Sargent 

20 Twilight Tiffany Tobey 

21 _ Twilight Tiffany Horiuchi 

22 _ Twilight Tiffany Graves 

23 __Waming Selma Chagall 

24 _Waming Selma Graves 

25 Waming Selma Sargent 

26 Wilkens Chris Tobey 

27 _ Wilkens Chris Graves 
Wilkens Ï Horiuchi 
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Deze view voegt TRANS, WORK en ARTIST samen en maakt de berekende kolom 
NetProfit. 


We kunnen NetProfit nu als volgt in een WHERE-clausule gebruiken: 


SELECT ArtistLastName, ArtistFirstName, 
WorkID, Title, Copy, DateSold, NetProfit 
FROM ArtistWorkNetView 
WHERE NetProfit > 5000 
ORDER BY DateSold; 


We maken hier gebruik van het resultaat van een berekening in een WHERE-clausu- 


le — iets wat niet is toegestaan in een enkelvoudig SQL-statement. Je ziet het resultaat 
in Figuur 7-25. 


WorkID Title Copy _DateSold NetProft | 


500 Memories IV Unique 2005-12-14 … _ 1250000 | 
548 ___Nioht Bird Unique 2006-11-28 … 1250000 | 
561 Sunflower Unique 2007-06-28. 750000 | 


570 Untitled Number 1 Unique 2007-09-29 … 625000 | 


571 Yellow Covers Blue Unique 2007-09-29 … 20000.00 | 


Memories IV Unique 2007-12-18 … 3250000 | 


Figuur 7-25 Resultaat SELECT met WHERE-clausule 


Er kunnen veel van dergelijke lagen worden gebruikt. We kunnen een tweede view 


definiëren die een berekening uitvoert op de berekende resultaten in de eerste view. 
Neem bijvoorbeeld: 


CREATE VIEW ArtistWorkTotalNetView as 
SELECT ArtistLastName, ArtistFirstName, WorkID, Title, 
Copy, SUM(NetProfit)as TotalNetProfit 


FROM ArtistWorkNetView 
GROUP BY ArtistLastName, ArtistFirstName, WorkID, Title, 
Copy; 


We kunnen TotalNetProfit nu als volgt gebruiken in een WHERE-clausule op de view 
ArtistWorkTotalNetView: 


SELECT * 
FROM ArtistWorkTotalNetView 
WHERE TotalNetProfit > 5000 


ORDER BY TotalNetProfit; 
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We maken in deze SELECT gebruik van een view op een view en we maken in de 
WHERE-clausule gebruik van een ingebouwde functie op een berekende variabele. 
Je ziet het resultaat in Figuur 7-26. 


ArtistlastName ArtistfirstName WorklD Te Copy TotalNet Profit 
beed À Mark 570 Untitled Number 1 _ Unique 6250.00 
2 Moris 561 Sunflower Unique 7500.00 
3 Graves Moris 548 Night Bird Unique _12500.00 
4 Horiuchi Paul 571 Yellow Covers Blue Unique 20000.00 


5 Horiuchi Paul 500 Memories IV Unique 


Figuur 7-26 Resultaat SELECT view op view en WHERE-clausule met ingebouwde functie op berekende variabele 


45000.00 


7.7.5 Views om code en tabellen te isoleren, voor permissies en voor 
triggers 

Views hebben nog drie andere belangrijke doeleinden. Ten eerste kunnen ze bronge- 

gevenstabellen en applicatiecode van elkaar isoleren. Stel dat we, om te zien hoe dat 

gaat, de volgende view definiëren: 


CREATE VIEW CustomerTable00lView AS 
SELECT % 
FROM CUSTOMER; 


Deze view kent de alias CustomerTableoorView toe aan de tabel CUSTOMER. Als 
alle applicatiecode de view CustomerTableoorView gebruikt dan is de werkelijke 
bron van de gegevens verborgen voor applicatieprogrammeurs. 

Het op deze manier isoleren van tabellen biedt het databasebeheerpersoneel flexi- 
biliteit. Stel bijvoorbeeld dat de bron van de klantengegevens op een gegeven mo- 
ment gewijzigd wordt in een andere tabel (die misschien uit een andere database is 
geïmporteerd) met de naam NEW_ CUSTOMER. De databasebeheerder moet in dat 
geval alleen CustomerTableoorView als volgt herdefiniëren: 


CREATE VIEW CustomerTable00lView AS 
SELECT * 
FROM NEW CUSTOMER; 


Alle applicatiecode die CustomerTableoorView gebruikt, zal nu probleemloos met 
de nieuwe gegevensbron werken. 

Een ander belangrijk doel van views is het toekennen van verschillende verza- 
melingen verwerkingspermissies aan dezelfde tabel. We zullen beveiliging gedetail- 
leerder bespreken in hoofdstuk 9 en 10. Je moet op dit moment alleen weten dat het 


mogelijk is permissies voor invoegen, bijwerken, verwijderen en lezen te beperken 
voor tabellen en views. 
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Een organisatie kan bijvoorbeeld een view van de tabel CUSTOMER maken met 
de naam CustomerReadView met alleen permissies voor lezen, en een tweede view 
met de naam CustomerUpdateView, met permissies voor lezen en schrijven. Ap- 
plicaties die de klantengegevens niet hoeven bij te werken, zullen met Customer- 
ReadView werken, terwijl applicaties die deze gegevens moeten bijwerken met 
CustomerUpdateView zullen werken. 

Een laatste reden voor het gebruik van views is dat het hiermee mogelijk is meer 
reeksen triggers op dezelfde brongegevens te definiëren. Deze techniek wordt vaak 
gebruikt voor het afdwingen van O-M- en M-M-relaties. Er is in dat geval een view 
met een reeks triggers die het verwijderen van een vereiste child verbiedt, en een an- 
dere view met een reeks triggers die zowel een parent als een vereiste child verwijde- 
ren. Deze views worden aan verschillende applicaties toegekend, afhankelijk van het 
gezag van deze applicaties. 


7.7.6 Views bijwerken 
Sommige views kunnen worden bijgewerkt en andere niet. De regels waarmee dat 
wordt bepaald, zijn zowel ingewikkeld als afhankelijk van het gebruikte DBMS. Kijk 


eens naar de volgende twee bijwerkverzoeken op de views uit de vorige paragraaf om 
te begrijpen waarom dat zo is:\ 


UPDATE CustomerTable001lView 


SET Email = 'NewEmailAddress@somewhere.com' 
WHERE CustomerID = 1000; 


en 


UPDATE ArtistWorkTotalNetView 
SET TotalNetProfit = 23000 
WHERE _ArtistLastName = 'Tobey'; 


Het eerste verzoek kan probleemloos worden verwerkt, want CustomerTableoorView 
heeft precies dezelfde structuur als de tabel CUSTOMER — het is gewoon een alias 
voor die tabel. De tweede updateaanvraag is daarentegen onzinnig. TotalNetProfit is 
een som van een berekende kolom. Een dergelijke kolom kan nergens in de data- 
base worden bijgewerkt. Het zal duidelijk zijn dat de tweede update niet kan worden 
verwerkt. 

Figuur 7-27 toont richtlijnen voor het bepalen of een view kan worden bijgewerkt. 
In het algemeen geldt dat het DBMS in staat moet zijn de bij te werken kolom (men) 
aan een specifieke rij in een specifieke onderliggende tabel te koppelen, om deze te 
kunnen bijwerken. Een manier waarop je deze vraag kunt aanpakken, is jezelf te 
vragen: “Wat zou ik doen als ik het DBMS was en mij gevraagd werd deze view bij te 
werken? Is dit een zinvol verzoek? Zo ja, zou ik voldoende gegevens hebben voor het 
uitvoeren van de update?’ De view zal zeker bij te werken zijn als de hele tabel aan- 
wezig is en er geen berekende kolommen zijn. 
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| views die kunnen worden bijgewerkt: 


e Een op een enkele tabel gebaseerde view zonder berekende 
kolommen, waarvan alle niet-null-kolommen in de view voorkomen. 

* Een op een willekeurig aantal tabellen gebaseerde view, met of zonder 
berekende kolommen, waarvoor een INSTEAD OF-trigger is gedefinieerd. 


Views die misschien zullen kunnen worden bijgewerkt: 


° Op een enkele tabel gebaseerd, primaire sleutel in de view, sommige 
vereiste kolommen ontbreken in de view. Update en delete zullen 
misschien zijn toegestaan. Invoegen is niet toegestaan. 

e Gebaseerd op meer tabellen. Updates zullen misschien zijn toegestaan 
voor de meest ondergeschikte tabel in de view, als rijen van die tabel op 
een unieke manier kunnen worden geïdentificeerd. 


Figuur 7-27 Richtlijnen voor het bijwerken van views 


De view kan niet worden gebruikt voor invoegen als er vereiste (NOT NULL) kolom- 
men ontbreken in de view. Een dergelijke view kan echter wel worden gebruikt voor 
updates en verwijderingen, mits de primaire sleutel (of, voor sommige DBMS-pro- 
ducten, een kandidaat-sleutel) in de view voorkomt. Views die meer tabellen weer- 
geven, kunnen de meest ondergeschikte tabel misschien bijwerken, als de primaire 
sleutel of een kandidaat-sleutel voor die tabel in de view voorkomt. 

Alle views waarvoor een INSTEAD OF-trigger is gedefinieerd, worden als bijwerk- 
baar gezien. Het DBMS zal de INSTEAD OF-trigger op de verderop in dit hoofdstuk 
beschreven manier aanroepen als het de updateaanvraag ontvangt. 


7.8 SQL opnemen in programmacode 


SQL-statements kun je opnemen in applicaties, triggers en opgeslagen procedures. 
We moeten echter eerst uitleggen hoe SQL-statements in programmacode worden 
opgenomen, voordat we deze onderwerpen kunnen bespreken. 

Er moeten twee problemen worden opgelost. Ten eerste is er een manier nodig 
om de resultaten van SQL-staterments aan programmavariabelen te kunnen toeken- 
nen. Daar worden veel verschillende technieken voor gebruikt. Het volgende state- 
ment kent bijvoorbeeld de telling van het aantal rijen in de tabel CUSTOMER toe 
aan de variabele rowcount in PL/SQL, de eigen taal van Oracle: 


SELECT Count(*) INTO rowCount 
FROM CUSTOMER; 


Een soortgelijk statement in T-SQL van SQL Server is: 


SELECT @rowCount = Count(*) 
FROM CUSTOMER; 
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Het uitvoeren van deze code plaatst in beide gevallen het aantal rijen in CUSTOMER 
in de programmavariabele rowcount of @ rowcount. 

Een tweede probleem heeft te maken met een verschillend uitgangspunt tussen 
SQL en programmeertalen. SQL is gericht op tabellen — SQL SELECT-statements 
hebben een of meer tabellen als input en leveren een tabel als output. Programma's 
daarentegen beginnen met een of meer variabelen, doen daar iets mee en slaan het 


resultaat dan op in een variabele. Een statement zoals het volgende is vanwege dat 
verschil onzinnig: 


SELECT LastName INTO custLastName 
FROM CUSTOMER; 


Heeft de tabel CUSTOMER honderd rijen, dan zullen er honderd waarden zijn voor 
LastName. De programmavariabele custLastName verwacht echter maar één waarde 
te krijgen. 

De resultaten van SQL-statements worden als pseudobestanden behandeld om 
dat probleem te vermijden. Er wordt een cursor, oftewel een verwijzing naar een be- 
paalde rij, opgezet als een SQL-statement een verzameling rijen levert. De applicatie 
kan de cursor dan op de eerste, de laatste of een willekeurige andere rij in de uitvoer 
van het SQL-statement plaatsen. Is de cursor geplaatst, dan kunnen er waarden van 
kolommen van deze rij aan programmavariabelen worden toegekend. Is de applica- 
tie klaar met een bepaalde rij, dan zal deze de cursor naar de volgende, de vorige of 


een willekeurige andere rij verplaatsen en verdergaan met het verwerken. 
Het gebruikelijke patroon ziet er zo uit: 


Open SQL (SELECT * FROM CUSTOMER); 
Verplaats cursor naar eerste rij; 
While cursor niet voorbij het eind van de resultaten { 
Set custLastName = LastName; 
. overige statements . 
Verplaats cursor naar de volgende rij; 
); 
. overige verwerking . 


Op deze manier worden de rijen van een SQL SELECT-statement één voor één 
verwerkt. 


Je zult in de volgende hoofdstukken veel voorbeelden zien van deze en andere 
vergelijkbare technieken. Je hoeft op dit moment alleen te proberen een intuïtief be- 
grip te ontwikkelen van hoe SQL in programmacode wordt ingevoegd. 
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7.9 _Triggers gebruiken 


Een trigger is een opgeslagen programma dat door het DBMS wordt uitgevoerd als 
een bepaalde gebeurtenis optreedt. Triggers voor Oracle worden geschreven in Java, 
of in de eigen taal van Oracle: PL/SQL (Programming Language for SQL). Triggers 
voor SQL Server worden geschreven in de eigen taal van SQL Server: Transact-SQL 
of T-SQL. Ze kunnen ook in gewone programmeertalen worden geschreven als Vi- 
sual Basic ‚NET, C# en C++. We bespreken triggers in dit hoofdstuk op een algemene 
manier, zonder specifiek op enigerlei taal in te gaan. In T-SQL geschreven triggers 
komen ter sprake in hoofdstuk ro. 

Een trigger is aan een tabel of een view gekoppeld. Een tabel of een view kan veel 
triggers hebben, maar een trigger is altijd aan maar één tabel of view gekoppeld. 

Een trigger wordt aangeroepen als er een insert-, update- of delete-bewerking 
wordt aangevraagd voor de tabel of de view waaraan de trigger is gekoppeld. Oracle 
ondersteunt drie soorten triggers: BEFORE, INSTEAD OF en AFTER. BEFORE-trig- 
gers worden, zoals je ook zou verwachten, uitgevoerd voordat het DBMS de insert-, 
update- of delete-bewerking verwerkt. INSTEAD OF-triggers worden uitgevoerd in 
plaats van de DBMS-verwerking voor de aangevraagde insert-, update- of delete- 
bewerking. AFTER-triggers worden uitgevoerd nadat de insert-, update- of delete- 
bewerking is gedaan. Er zijn in totaal negen soorten triggers mogelijk: BEFORE 
(Insert, Update, Delete), INSTEAD OF (Insert, Update, Delete) en AFTER (Insert, 
Update, Delete). 

SQL Server ondersteunt alleen INSTEAD OF- en AFTER-triggers en kent dus 
maar zes mogelijke typen triggers. Andere DBMS-producten ondersteunen triggers 
op andere manieren. Zie de documentatie van je product om te bepalen welke typen 
triggers het ondersteunt. 

Als een trigger wordt uitgevoerd, stelt het DBMS de gegevens die betrokken zijn 
bij de gevraagde actie ter beschikking aan de triggercode. Het DBMS levert in het 
geval van invoegen de waarden van de kolommen voor de nieuwe rij. Bij verwij- 
deringen levert het DBMS de waarden van de kolommen van de verwijderde rij. 
Bij updates levert het zowel de oude als de nieuwe waardeDe manier waarop de 
waarden worden geleverd, is afhankelijk van het DBMS-product. Neem voorlopig 
aan dat nieuwe waarden worden geleverd door de uitdrukking new: voor een kolom- 
naam te plaatsen. Dus, bij een invoegbewerking op CUSTOMER bevat de variabele 
new:LastName de waarde van LastName voor de in te voegen rij. 

Neem verder ook aan dat oude waarden worden geleverd door old: voor een kolom- 
naam te plaatsen. Dus bij een verwijderbewerking bevat de variabele old:LastName 
de waarde van LastName uit de te verwijderen rij. Bij een update heeft old:LastName 
de waarde die LastName had voordat de aangevraagde update werd uitgevoerd. (Dit 
is in feite de strategie van Oracle. Je zult in hoofdstuk to de equivalente strategie van 
SQL Server zien.) 

Er zijn veel doeleinden voor triggers. We behandelen in dit hoofdstuk vier doel- 
einden, die zijn weergegeven in Figuur 7-28. 
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e Leveren van defaultwaarden 
e Afdwingen van data constraints 
e Bijwerken van views 


e Uitvoeren van referential 
integrity-acties 


Figuur 7-28 Gebruiksdoelen van triggers 


7.9.1 Triggers voor defaultwaarden 

In paragraaf 7.3.9 zag je hoe je een beginwaarde voor een kolom kunt opgeven met 
het sleutelwoord DEFAULT. Dit werkt alleen voor eenvoudige waarden, of voor resul- 
taten van eenvoudige berekeningen. Er is een trigger nodig als achter de berekening 
van een defaultwaarde ingewikkelde logica zit. 

Stel bijvoorbeeld dat galerie View Ridge een beleid heeft dat de waarde van 
AskingPrice gelijk moet zijn aan de grootste van twee waarden: tweemaal de Aquisi- 
tionPrice, of de som van de AquisitionPrice plus de gemiddelde nettowinst op vorige 
verkopen van dit werk. De AFTER-trigger in onderstaande code implementeert dit 
beleid. 

De trigger declareert programmavariabelen en telt dan het aantal TRANS-rijen 
voor dit werk en plaatst de telling in de variabele rowcount. De nieuwe TRANS-rij zal 
al zijn ingevoegd, want dit is een AFTER-trigger, en de telling zal r zijn als dit de eer- 
ste keer is dat het werk in de galerie is. Is dat het geval, dan wordt de nieuwe waarde 
van SalesPrice ingesteld op tweemaal de AquisitionPrice. 

Is het aantal rijen groter dan 1, dan is het werk al eerder in de galerie geweest. 
We kunnen dan de in paragraaf 7.7.4 beschreven ArtistWorkNetView gebruiken voor 
het berekenen van de gemiddelde winst voor dit werk. Het volgende SQL-statement 
gebruikt deze view voor het berekenen van Sum(NetProfit) voor dit werk. Deze som 
wordt in de variabele sumNetProfit geplaatst. Merk op dat de WHERE-clausule al- 
leen rijen voor dit werk selecteert. Daarna wordt het gemiddelde berekend door de 
som te delen door de rijtelling min 1. 

Je vraagt je misschien af waarom we niet gebruikmaken van Avg(NetProfit) in het 
SQL-statement. Het antwoord is dat de standaard SQL-functie de nieuwe rij mee zou 
hebben genomen in de berekening van het gemiddelde. We willen niet dat deze rij 
in de berekening wordt opgenomen en trekken daarom 1 af van rowcount als we het 
gemiddelde berekenen. 

De berekende waarde van avgNetProfit wordt daarna vergeleken met tweemaal 


de AquisitionPrice — de hoogste waarde wordt gebruikt als de nieuwe waarde voor 
AskingPrice. 
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at het Kunstwerk In de qa rie ver an B Be 


wr AcquistionPrice) } 


Figuur 7-29 Triggercode voor een defaultwaarde 


7.9.2 Triggers voor het afdwingen van data constraints 

Een tweede doel voor triggers is het afdwingen van data constraints. Er kunnen wel- 
iswaar SQL CHECK-constraints worden gebruikt voor het afdwingen van domein-, 
bereik- en intrarelatieconstraints, maar geen enkele DBMS-leverancier heeft de voor- 
zieningen van SQL-92 geïmplementeerd voor interrelatie-CHECK-constraints. Der- 
gelijke constraints worden daarom in triggers geïmplementeerd. 

Laten we bijvoorbeeld eens aannemen dat de galerie speciaal is geïnteresseerd 
in Mexicaanse schilders en dat de galerie nooit kortingen toepast op hun kunstwer- 
ken. Dat betekent dat de SalesPrice van een kunstwerk altijd minstens even hoog 
moet zijn als de AskingPrice. De database van de galerie handhaaft deze regel met 
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CREATE TRIGGER TRANS _CheckSalesPrice 
AFTER INSERT, UPDATE ON TRAKS 


DECLARE 


artistNationaldty char ZOM 
BEGIN 
& /* Bepaal eb ner ki r n ee 1 1 
CT a na li 
WHERE 1 r 
IF artistNationality © ‘Mexican’ 
THEN 
Exit Trigger ; 
ELSE 
/* Het kunstwerk 1s van een Mexicaanse kunstenaar handhaaf de c traint 
Bi, 
IF (new:sSalesPrice < newzsAskingPrice) 
THEN 
/* Sales Price is te laag, reset 
UPDATE 
SET ice = new:AskingPrice 
J* Opmerking : de voorgaande update zal een recursieve aanroep naar * 
/* deze trigger veroorza à recurs al ophouden * 
/* tijdens de tweede doorgang. omdat Se Be Wij 
{* dan gelijk zal zijn aan AskingPrice. */ 
/* Meld aan de gebruiker te melden wat er is gedaan. */ 
END IF 
END ; 


Figuur 7-30 Een trigger voor het afdwingen van een interrelatiedataconstraint 


een insert-/bijwerktrigger op TRANS die controleert of het kunstwerk van een Mexi- 
caanse schilder is. Zo ja, dan wordt de SalesPrice met de AskingPrice vergeleken. Is 
de SalesPrice lager dan de AskingPrice, dan wordt de SalesPrice teruggezet op de 
AskingPrice. 

Figuur 7-30 toont algemene triggercode die deze regel afdwingt. Deze trigger 
start na elke invoeging of update van een TRANS-rij. De trigger controleert eerst of 
het kunstwerk van een Mexicaanse kunstenaar is. Is dat niet het geval, dan wordt 
de trigger verlaten. Is dat wel het geval, dan wordt SalesPrice met de AskingPrice 
vergeleken — is deze lager dan de AskingPrice, dan wordt SalesPrice op AskingPrice 
ingesteld. 

Deze trigger wordt recursief aangeroepen. Het updatestatement in de trigger ver- 
oorzaakt een update in TRANS, die ertoe zal leiden dat de trigger opnieuw wordt 
aangeroepen. De SalesPrice zal de tweede keer echter gelijk zijn aan de AskingPrice, 
zodat er geen updates volgen en de recursie ophoudt. 
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7.9.3 Views bijwerken 

Zoals we in paragraaf 7.7.6 vermeldden, kan het DBMS sommige views wel en an- 
dere niet bijwerken, afhankelijk van de manier waarop de view is opgebouwd. Views 
die het DBMS niet kan bijwerken, kunnen soms door applicaties worden bijgewerkt 
door specifieke logica voor een bepaalde bedrijfsomgeving toe te passen. De applica- 
tiespecifieke logica voor het updaten van de view wordt in dat geval in een INSTEAD 
OF-trigger opgenomen. 

Als een INSTEAD OF-trigger aan een view is gekoppeld, zal het DBMS alleen 
de trigger aanroepen en verder geen enkele actie ondernemen. Alles wordt verder 
aan de trigger overgelaten. Zou je een INSTEAD OF INSERT-trigger aan de view 
MijnView koppelen en deze trigger zou alleen maar een e-mail versturen, dan is die 
e-mail het resultaat van een INSERT op de view. INSERT MijnView betekent dan 
‘Verstuur een e-mail’ en verder niets. 


COUNT C * ) into rowcount 
CUSTOMER 
CUSTOMER, Last Name old: LastName 
IF rowcount = 1 
THEN 
Als we nier komen is er maar éér ant m je naam. */ 
/* Voer de naamwijziaing uit. */ 


UPDATE CUSTOMER 


SET CUSTOMER. La 

WHERE CUSTOMER. Last Name 

ELSE 

/* Stuur een melding naar de gebruiker die h 


/” dat we niet Kunnen updaten, omdat er teve 
/* klanten zijn met de originele naam. */ 


ENDERS 
END ; 


Figuur 7-31 Een trigger voor het bijwerken van een view 
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Kijk nu eens naar de meer realistische view CustomerlInterestsView in paragraaf 
7.7.3 en het resultaat daarvan in Figuur 7-24. Deze view is het resultaat van twee 
joins over de intersectietabel tussen CUSTOMER en ARTIST. Stel dat deze view de 
gegevens in een gebruikersformulier invult. Stel verder dat de gebruikers zo nodig 
de namen van klanten in dit formulier moeten kunnen corrigeren. Als dergelijke wij- 
zigingen niet mogelijk waren, dan zouden de gebruikers iets zeggen als: ‘Maar die 
naam klopt niet! Waarom kan ik die hier niet veranderen” Zij hebben er geen idee 
van hoeveel moeite het DBMS heeft moeten doen om die gegevens weer te geven! 

De view omvat hoe dan ook voldoende informatie om de naam van de klant te 
kunnen bijwerken, mits de waarde van de naam van de klant uniek is binnen de da- 
tabase. Figuur 7-31 toont algemene triggercode voor een dergelijke update. De code 
telt gewoon het aantal klanten met de oude waarde van LastName. De update wordt 
uitgevoerd als er maar één klant is die deze waarde heeft. Is dat niet het geval, dan 
wordt er een foutmelding geleverd. Merk op dat de update wordt toegepast op een 
van de tabellen waarop de view is gebaseerd. De view zelf bevat natuurlijk geen echte 
gegevens. Alleen de echte tabellen kunnen worden bijgewerkt. 


7.9.4 Referential integrity-acties 


Het vierde doel voor triggers is het implementeren van referentiële integriteitsacties. 
Neem bijvoorbeeld de r:N-relatie tussen AFDELING en WERKNEMER. Neem aan 
dat de relatie M-M is en dat WERKNEMER. Afdelingsnaam een foreign key is voor 
AFDELING. 

We maken twee views om deze constraint af te dwingen. Beide views zijn geba- 
seerd op WERKNEMER. De eerste view, Verwijder WerknemerView, verwijdert al- 
leen een rij uit WERKNEMER als deze rij niet de laatste child is in de AFDELING. 
De tweede view, VerwijderWerknemerAfdelingView, verwijdert een rij uit WERK- 
NEMER en als die rij de laatste WERKNEMER is in de AFDELING, dan verwijdert 
de view de AFDELING-rij. 

Een organisatie stelt de view VerwijderWerknemerView ter beschikking aan ap- 
plicaties die geen permissie hebben om een rij uit AFDELING te verwijderen. De 
view VerwijderWerknemerAfdelingView wordt ter beschikking gesteld aan applica- 
ties die permissie hebben niet alleen werknemers te verwijderen, maar ook afdelin- 
gen die geen werknemers hebben. 


De views VerwijderWerknemer en VerwijderWerknemerAfdelingView hebben 
dezelfde structuur: 


CREATE VIEW VerwijderWerknemerView 
SELECT * 


FROM WERKNEMER; 
CREATE VIEW VerwijderWerknemerAfdelingView 


SELECT xe 
FROM WERKNEMER; 
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7.9.5 Een trigger voor VerwijderWerknemerView 
De trigger voor VerwijderWerknemerView, die je in Figuur 7-32 ziet, bepaalt of de 
werknemer de laatste werknemer in de afdeling is. Is dat niet het geval, dan wordt 
de rij uit WERKNEMER verwijderd. Is dat wel het geval, dan wordt er niets gedaan. 
Nogmaals, het DBMS doet zelf niets als er een INSTEAD OF-trigger is gedecla- 
reerd voor de verwijdering. Alle activiteit wordt aan de trigger overgelaten. Deze trig- 
ger doet niets als de werknemer de laatste werknemer in de afdeling is. Dat betekent 
dat er geen wijziging in de database zal worden uitgevoerd, want het DBMS heeft alle 
verwerkingstaken aan de INSTEAD OF-trigger overgelaten. 


„T ror ER WERENEMER V 4 
ATE TRIGGER WERKNEMER Verwijder 


Figuur 7-32 Een trigger voor het verwijderen van een rij, behalve de laatste child 


7.9.6 Een trigger voor VerwijderWerknemerAfdelingView 
De trigger voor Verwijder WerknemerAfdelingView, die je in Figuur 7-33 ziet, verwij- 
dert de werknemer en controleert of dat de laatste werknemer in de afdeling was. Is 
dat het geval, dan wordt de AFDELING verwijderd. 

Triggers zoals die in Figuur 7-32 en Figuur 7-33 worden gebruikt voor het afdwin- 
gen van de referential integrity-acties voor O-M- en M-M-relaties, zoals beschreven 
aan het eind van hoofdstuk 6. Je leert in hoofdstuk ro hoe je ze schrijft voor SQL 


Server. 
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CREATE TRIGGER WERKNEMER AFDELING VerwijderControle 
INSTEAD OF DELETE ON VerwijderWerknemerAfaelingView 


DECLARE 
row nt nt 
BEGIN 
/* Verwijder de rij Ë na | El Û | € | 
DELETE 
WHERE Ì r 
/* Bepaal of dit [ 
SELECT ur 
FROM 
WHERE ! r er fi 
LF rowcount 
THEN 
/* Geen werknemers, verwijder rij uit AFDELING * 
DELETE AFDELING 
WHERE AFDELING.Afdelingsnaan old:Afdel ingsnaam 
ENDE: 
END : 


Figuur 7-33 Een trigger voor het verwijderen van een child en, zo nodig, van de parent 


7.10 Opgeslagen procedures 


Een opgeslagen procedure (stored procedure) is een in een database opgeslagen pro- 
gramma dat een bepaalde algemene actie uitvoert op de gegevens in de database. Op- 
geslagen procedures kunnen in Oracle worden geschreven in PL/SQL of in Java. Ze 
worden met SQL Server geschreven in T-SQL of in .NET met zogeheten Common 
Language Runtime (CLR)-talen als Visual Basic ‚NET, C#.NET of C++.NET. 

Opgeslagen procedures kunnen invoerparameters ontvangen en resultaten leve- 
ren. Ze zijn aan de database zelf gekoppeld, in tegenstelling tot triggers, die aan een 
gegeven tabel of view zijn gekoppeld. Ze kunnen worden uitgevoerd door elk wille- 
keurig proces dat van de database gebruikmaakt en dat voldoende permissies heeft 
om de procedure te gebruiken. 

Opgeslagen procedures worden gebruikt voor allerlei doeleinden. Databasebe- 
heerders gebruiken ze weliswaar ook voor het uitvoeren van algemene beheersta- 
ken, maar ze worden voornamelijk toegepast vanuit databaseapplicaties. Ze zijn uit 
te voeren vanuit applicaties die geschreven zijn in talen als COBOL, C, Java, C# of 
C++. Ze zijn ook aan te roepen vanuit webpagina's door VBScript of JavaScript te ge- 
bruiken. Ad-hocgebruikers kunnen ze uitvoeren vanuit producten zoals SQL*Plus of 
SQL Developer in Oracle, of vanuit SQL Server Management Studio in SQL Server. 


7.10.1 Voordelen van opgeslagen procedures 

Figuur 7-34 noemt de voordelen van het gebruik van opgeslagen procedures. Opge- 
slagen procedures worden in tegenstelling tot applicatiecode nooit aan clientcom- 
puters gedistribueerd. Ze worden altijd in de database bewaard en worden door het 
DBMS verwerkt op de databaseserver. Ze zijn daarom veiliger dan gedistribueer- 
de applicatiecode en ze verminderen bovendien het netwerkverkeer. Steeds vaker 
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wordt de voorkeur gegeven aan opgeslagen procedures voor het verwerken van ap- 
plicatielogica over internet of een bedrijfsintranet. Nog een voordeel van opgesla- 
gen procedures is dat hun SQL-statements kunnen worden geoptimaliseerd door de 
DBMS-compiler. 


Betere beveiliging 

Minder netwerkverkeer 

SQL kan worden geoptimaliseerd 
Code kan worden gedeeld 

Minder werk 
Gestandaardiseerde verwerking 
Specialisatie onder ontwikkelaars 


Figuur 7-34 Voordelen van opgeslagen procedures 


Veel verschillende applicaties kunnen dezelfde applicatielogica delen als deze code 
in een opgeslagen procedure wordt geplaatst. Dat betekent niet alleen minder werk, 
maar ook een gestandaardiseerde verwerking. 

Vanwege deze voordelen zullen opgeslagen procedures in de toekomst vermoede- 
lijk steeds vaker worden gebruikt. 


7.10.2 De opgeslagen procedure WORK_AddWorkTransaction 

Figuur 7-35 toont een opgeslagen procedure die de aanschaf van een werk door ga- 
lerie View Ridge registreert. Deze code is algemeen, maar de stijl van de code komt 
dichter in de buurt van de stijl van SQL Server — in tegenstelling tot de meer Oracle- 
achtige stijl die we gebruikten voor de voorbeelden van triggers in de vorige para- 
graaf. Je kunt een gevoel krijgen van de verschillen tussen PL/SQL en T-SQL door de 
voorbeelden in beide paragrafen met elkaar te vergelijken. 


CREATE PROCEDURE WORK _AddWorkTransaction 
( 
@ArtistID int, /* De kunstenaar moet al bestaan in de 
database */ 
@Title char(25), 
@Copy char(8), 
@Description varchar(1000), 
@AcquisitionPrice Numeric(6,2) 
) 


/* Opgeslagen procedure voor het registreren van de aankoop 
van een werk. Voeg een nieuwe rij toe aan WORK als het werk 
nooit eerder in de galerie is geweest. Gebruik anders de 
bestaande rij in WORK, voeg een nieuwe TRANS-rij toe voor 
het werk en stel DateAquired in op de systeemdatum Eef 


Figuur 7-35 Een opgeslagen procedure voor het registreren van de aankoop van een werk 
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AS 
DECLARE @rowcount AS int 
DECLARE @WorkID AS int 


/* Controleer eerst of ArtistiD geldig is ij 
SELECT @rowcount = COUNT(*) 

FROM ARTIST AS A 

WHERE A.ArtistID = @ArtistID 


IF (@rowcount = 0) 

/* De kunstenaar is niet gevonden! ka 
BEGIN 

Print ‘Geen kunstenaar met de ID ' + Str(@artistID) 

Print ‘Verwerking beëindigd.’ 

RETURN 

END 


[* Kijk nu of het werk voorkomt in de database kei 
SELECT @rowcount = COUNT(*) 
FROM WORK AS W 
WHERE W.ArtistID = @ArtistID and 
W.Title = @Title and 
W.Copy = @Copy 


IF (@rowcount = 0) 
BEGIN 
/* Komt niet in database voor, dus voeg in koi 
INSERT INTO WORK (Title, Copy, Description, ArtistID) 


VALUES (@Title, @Copy, @Description, @ArtistID) 
END 


/* Haal de waarde op voor de surrogate key van het werk ijf 
SELECT @WorkID = W.WorkID 
FROM WORK AS W 
WHERE W.ArtistID = @ArtistID and 
W.Title = @Title and 
W.Copy = @Copy 


/* Neem nu de TRANS-rij op in de database iff 
INSERT INTO TRANS (DateAcquired, AcquisitionPrice, WorkID) 
VALUES (GetDate(), @AcquisitionPrice, @workID) 


RETURN 


Figuur 7-35 (vervolg) 
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De procedure WORK _AddWorkTransaction ontvangt vijf parameters en levert niets. 
In een meer realistisch voorbeeld zou er een waarde aan de aanroeper worden gele- 
verd om aan te geven of de bewerking is geslaagd of mislukt. Het bespreken daarvan 
zou ons echter van het onderwerp van databaseconcepten afbrengen en we laten dat 
hier daarom achterwege. 

Deze code gaat er niet van uit dat de doorgegeven waarde van ArtistID een geldige 
ID is. Het eerste blok statements telt het aantal rijen met de gegeven ArtistI D-waar- 
de. Is dat aantal nul, dan is de waarde van ArtistID ongeldig. De procedure schrijft in 
dat geval een foutmelding en keert terug. 

Is de waarde niet nul, dan controleert de procedure daarna of het werk al eerder 
in de galerie is geweest. Is dat het geval, dan zal de tabel WORK al een rij bevatten 
voor deze ArtistlD, Title en Copy. Bestaat een dergelijke rij niet, dan zal de procedure 
een nieuwe rij maken in WORK. Daarna wordt een waarde voor WorkID verkregen 
door een SELECT te gebruiken. Dat statement is nodig als de rij in WORK net is 
gemaakt, om de nieuwe waarde van de surrogate key WorkID te verkrijgen. Is het 
werk niet net gemaakt, dan is de SELECT op WorkID nodig om de WorkID van de 
bestaande rij te verkrijgen. 

De nieuwe rij kan nu in TRANS worden ingevoegd, nu er een waarde van Work- 
ID is verkregen. Merk op dat de systeemfunctie GetDate() wordt gebruikt voor het 
leveren van een waarde voor DateAquired in de nieuwe rij. We laten je deze procedu- 
re zien om je een algemeen idee te geven van hoe SQL wordt gebruikt in opgeslagen 
procedures. Het voorbeeld is niet volledig. Dat komt voornamelijk omdat we nog iets 
moeten doen om te garanderen dat alle updates in de database worden uitgevoerd, 
of geen daarvan. Je zult in hoofdstuk g zien hoe dat wordt gedaan. Je hoeft je er hier 
alleen op te concentreren hoe de SQL die je in het vorige hoofdstuk leerde, kan wor- 
den gebruikt als een onderdeel van een databaseapplicatie. 


Samenvatting 


SQL data definition language (DDL)-statements worden gebruikt voor het beheren 
van de structuur van tabellen. In dit hoofdstuk presenteerden we drie SQL DDL-state- 
ments: CREATE TABLE, ALTER TABLE en DROP TABLE. SQL heeft de voorkeur bo- 
ven grafische tools voor het maken van tabellen, want SQL is sneller en kan worden 
gebruikt om dezelfde tabel herhaald te maken. Met SQL kunnen tabellen worden ge- 
maakt vanuit programmacode en SQL is gestandaardiseerd en DBMS-onafhankelijk. 

Het datatype IDENTITY (N, M) wordt gebruikt voor het maken van surrogate 
key-kolommen, waarbij N de beginwaarde is en M de waarde is waarmee wordt 
vermeerderd. Het SQL-statement CREATE TABLE wordt gebruikt voor het definië- 
ren van de naam van de tabel, de kolommen ervan en constraints voor deze kolom- 
men. Er zijn vijf soorten constraints: PRIMARY KEY, UNIQUE, NULL/NOT NULL, 


3 Deze code controleert niet of er meer rijen zijn met de gegeven Artist[D. Zie je waarom die controle niet 
nodig is? Artist[D is een surrogate key. Het DBMS zal daarom nooit toestaan dat twee rijen dezelfde waar- 
de hebben. 
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FOREIGN KEY en CHECK. Het doel van de eerste drie soorten ligt voor de hand. 
FOREIGN KEY wordt gebruikt voor het maken van referential integrity constraints 
en CHECK voor het maken van data constraints. Figuur 7-8 vat technieken samen 
voor het maken van relaties met SQL-constraints. 

Eenvoudige defaultwaarden kunnen worden toegekend met het sleutelwoord DE- 
FAUILT. Data constraints worden gedefinieerd met CHECK-constraints. Er kunnen 
domein-, bereik- en intratabelconstraints worden gedefinieerd. Weliswaar werden er 
voorzieningen voor interrelatie-CHECK-constraints gedefinieerd in SQL-92, maar 
deze voorzieningen zijn niet geïmplementeerd door de leveranciers van DBMS'’en. 
Interrelatieconstraints worden in plaats daarvan met triggers afgedwongen. 

Het statement ALTER wordt gebruikt voor ht toevoegen en verwijderen van ko- 
lommen en constraints. Het statement DROP wordt gebruikt voor het verwijderen 
van tabellen. Parents moeten in SQL DDL het eerst worden gemaakt en het laatst 
worden verwijderd. 

De SQL data manipulation language (DML)-statements zijn INSERT, UPDATE 
en DELETE. Elk van deze statements kan worden gebruikt op een enkele rij, op een 
groep van rijen of op een hele tabel. UPDATE en DELETE zijn zo krachtig dat je 
voorzichtig moet zijn met het gebruik ervan. 

De opdracht JOIN ON is volgens sommige mensen een makkelijker vorm van 
join. Rijen waarvoor geen overeenkomst wordt gevonden in de join constraint, wor- 
den uit de resultaten van de join weggelaten. Gebruik een LEFT OUTER of een 
RIGHT OUTER join in plaats van een gewone of INNER join om dergelijke rijen te 
behouden. 

Een SQL-view is een virtuele tabel die wordt gemaakt op basis van andere tabel- 
len en views. Views worden gedefinieerd met SQL SELECT-statements. De enige 
beperking is dat de definitie van een view geen ORDER BY-clausule mag omvatten. 

Views worden gebruikt voor het verbergen van kolommen en rijen, voor het 
weergeven van de resultaten van berekende kolommen en voor het verbergen van 
ingewikkelde SQL-syntaxis, zoals die voor joins en GROUP BY-query's. Sommige 
organisaties passen views toe voor het leveren van een indirecte verbinding tussen 
applicaties en tabellen. Views kunnen ook worden gebruikt voor het toekennen van 
verschillende verzamelingen verwerkingspermissies en verschillende verzamelin- 
gen triggers aan tabellen. 

De regels die bepalen of een view kan worden bijgewerkt, zijn zowel ingewikkeld 
als DBMS-specifiek. Je ziet richtlijnen hiervoor in Figuur 7-27. 

SQL kan in programmacode worden ingevoegd in triggers, opgeslagen proce- 
dures en applicatiecode. Daartoe moet een methode worden bedacht die SQL- 
tabelkolommen aan programmavariabelen koppelt. Er is ook een verschil tussen de 
paradigma's van SQL en programma's. De meeste SQL-statements leveren reeksen 
rijen — een applicatie verwacht met één rij tegelijk te werken. Dat verschil wordt op- 
gelost door de resultaten van SQL-statements te verwerken als pseudobestanden. 

Een trigger is een opgeslagen programma dat telkens door het DBMS wordt 
uitgevoerd als er een specifieke gebeurtenis optreedt voor een specifieke tabel of 
view. Triggers kunnen in Oracle worden geschreven in een eigen taal van Oracle 
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die Programming Language/SQL (PL/SQL) wordt genoemd. Ze kunnen ook in Java 
worden geschreven. Triggers kunnen in SQL Server worden geschreven in een eigen 
taal van SQL Server die TRANSACT-SQL (T-SQL) wordt genoemd of in Microsoft 
CLR-talen als Visual Basic .NET, C#.NET of C++.NET. 

Er zijn BEFORE-, INSTEAD OF- en AFTER-triggers mogelijk. Elk van deze soor- 
ten kan worden gedeclareerd voor Insert, Update en Delete — er zijn dus in totaal ne- 
gen soorten triggers. Oracle ondersteunt alle negen soorten. SQL Server ondersteunt 
alleen INSTEAD OF- en AFTER-triggers. 

Het DBMS levert oude en nieuwe waarden voor de update als een trigger wordt 
gestart. Nieuwe waarden worden geleverd voor invoegen en bijwerken, oude waar- 
den voor bijwerken en verwijderen. De manier waarop die waarden aan de trigger 
worden geleverd, is afhankelijk van het DBMS. 

Er zijn veel doeleinden voor triggers. Dit hoofdstuk bespreekt er vier: default- 
waarden, het afdwingen van interrelatieconstraints, het bijwerken van views en het 
afdwingen van referentiële integriteit. 

Een opgeslagen procedure is een programma dat in de database is opgeslagen en 
wordt gecompileerd bij het gebruik. Opgeslagen procedures kunnen in Oracle wor- 
den geschreven in PL/SQL of in Java. Ze kunnen in SQL Server worden geschreven 
in T-SQL. Opgeslagen procedures kunnen invoerparameters ontvangen en resulta- 
ten leveren. Hun bereik is, anders dan bij triggers, de hele database — ze kunnen 
door elk proces worden gebruikt dat permissies heeft om de in de database opgesla- 
gen procedure te gebruiken. 

Opgeslagen procedures kunnen worden aangeroepen vanuit programma’s die in 
dezelfde talen zijn geschreven als die gebruikt worden voor triggers. 

De voordelen van het gebruik van opgeslagen procedures zijn samengevat in 


Figuur 7-34. 


Belangrijke termen 


ALTER IDENTITY((Beginwaarde}, 
ALTER VIEW {Verhoging}) 

AS inner join 

CHECK INSERT 

CREATE TABLE interrelatieconstraint 
CREATE VIEW intrarelatieconstraint 
cursor JOIN ON 

data definition language (DDL) LEFT JOIN 


data manipulation language (DML) 
DEFAULT 

DELETE 

DROP TABLE 

FOREIGN KEY constraint 


left outer join 

losse relatie 

NOT NULL-constraint 
NULL-constraint 

ON DELETE 

ON UPDATE 
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opgeslagen procedure TOP 


outer join Transact SQL (T-SQL) 
PRIMARY KEY-constraint Trigger 
pseudobestand UNIQUE 

RIGHT JOIN UPDATE 

right outer join view 


stored procedure 


Oefeningen 


1. Waar is DDL de afkorting van? Noem de SQL DDL-statements. 
2. Waar is DML de afkorting van? Noem de SQL DML-statements. 
3. Leg uit wat de volgende expressie betekent: IDENTITY (4000,5). 


Gebruik de volgende drie tabellen in je antwoorden op vraag 4 tot en met 25; 
WERKNEMER (Werknemernummer, Naam, E-mail) 


PROJECT (Projectnaam, Beschrijving, Begindatum, Einddatum) 
TOEKENNING (Werknemernummer, Projectnaam, TotaalUrenGewerkt) 


Neem aan dat de relatie van WERKNEMER naar TOEKENNING en de relatie van 

PROJECT naar TOEKENNING beide r:N, M-O zijn. 

4. Schrijf een CREATE TABLE-statement voor de tabel WERKNEMER. Gebruik de 
in Figuur 7-4 getoonde datatypen van SQL Server. Neem aan dat Naam vereist is 
en dat deze een alternatieve sleutel is. E-mail is niet vereist en is ook geen alter: 
natieve sleutel. 

5. Schrijf een CREATE TABLE-statement voor PROJECT. Neem aan dat alleen Pro- 
jectnaam vereist is en dat geen enkele kolom een alternatieve sleutel is. Gebruik 
de in Figuur 7-4 getoonde datatypen van SQL Server. 

6. Schrijf een CREATE TABLE-statement voor TOEKENNING. Gebruik de tabel- 
len WERKNEMER en PROJECT uit je antwoorden op de vragen 4 en 5. Stel de 
defaultwaarde van Totaal UrenGewerkt in op 3. Geef wijzigingen in en verwijde 
ringen uit PROJECT cascading door aan TOEKENNING, maar geef alleen wij- 
zigingen in WERKNEMER cascading door. 

7. Verander je antwoord op vraag 5 en neem de constraint op dat Begindatum vóór 
Einddatum moet zijn. Beperk Projectnaam bovendien tot op de waarden Rood, 
Blauw en Geel. 

8. Verander je antwoord op vraag 6 en wijzig de relatie tussen WERKNEMER en 
TOEKENNING in een r:1-relatie. 

9. Schrijf een ALTER-statement dat de kolom Telefoon aan WERKNEMER toe- 
voegt. Neem aan dat Telefoon niet vereist is. 

ro. Schrijf een ALTER-statement dat de kolom E-mail uit WERKNEMER verwijdert. 

Ir. Schrijf een ALTER-statement dat Telefoon tot een alternatieve sleutel maakt in 
WERKNEMER. 
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Schrijf een ALTER-statement dat de constraint verwijdert dat waarden van Naam 
uniek moeten zijn in WERKNEMER. 


Neem in je antwoorden op vraag 13 tot en met 25 aan dat de tabel WERKNEMER 
de originele indeling heeft (Werknemernummer, Naam, E-mail). Neem aan dat de 
relatie van WERKNEMER naar TOEKENNING r‚N is. 


21. 


22. 


23 


24. 


25. 


26. 
27. 


28. 


Schrijf een INSERT-statement dat de rij (12345, ‘Jansen’, ‘Jansen@MijnBedrijf. 
com’) aan WERKNEMER toevoegt. 

Schrijf een INSERT-statement dat de rij (12345, ‘Jansen@MijnBedrijf.com’, Jan- 
sen) aan WERKNEMER toevoegt. 

Schrijf een INSERT-statement dat de rij (12345, Jansen) aan WERKNEMER 
toevoegt. 


. Neem aan dat je een tabel met de naam NIEUWE WERKNEMERS hebt, met 


de kolommen Naam en Werknemernummer — in die volgorde. Schrijf een 
INSERT-statement dat alle rijen van de tabel NIEUWE_WERKNEMERS aan 
WERKNEMER toevoegt. 

Schrijf een UPDATE-statement dat de naam van de werknemer ‘Jansen’ in 
‘Smit’ verandert. 

Schrijf een UPDATE-statement dat de waarde van E-mail van de werknemer 
‘Jansen’ in ‘Smit@MijnBedrijf.com' verandert. 


„ Combineer je antwoorden op vraag 16 en 17 in een enkel SQL-statement. 
„ Neem aan dat TOEKENNING en PROJECT geldige gegevens bevatten. Schrijf 


een UPDATE-statement dat TotaalUrenGewerkt op 15 instelt voor elke rij in 
TOEKENNING die de waarde 12345 heeft voor Werknemernummer. 

Neem aan dat je een tabel met de naam NIEUWE_E-MAIL hebt, die nieuwe 
waarden bevat voor de e-mailadressen van sommige werknemers. NIEUWE 
E-MAIL heeft twee kolommen: WerknemerNummer en NieuweE-mail. Schrijf 
een UPDATE-statement dat de waarden van E-mail in WERKNEMER wijzigt in 
de waarden uit de tabel NIEUWE_E-MAIL. 

Schrijf een DELETE-statement dat alle gegevens voor het project ‘BLAUW’ zal 
verwijderen, evenals alle rijen daarvan in TOEKENNING. 

Schrijf een DELETE-statement dat de rij voor de werknemer met de naam ‘Smit’ 
zal verwijderen. Wat gebeurt er als deze werknemer rijen in TOEKENNING 
heeft? 

Voeg WERKNEMER, TOEKENNING en PROJECT samen met behulp van de 
JOIN ON-syntaxis. 

Voeg WERKNEMER en TOEKENNING samen en neem alle rijen van WERK- 
NEMER in je antwoord op, ongeacht of deze een TOEKENNING hebben of niet. 
Wat is een SQL-view? Welk doel hebben views? 

Welke beperking wordt er aan SELECT-statements opgelegd die in SQL-views 
worden gebruikt? 

Schrijf een SQL-statement dat een view maakt die de waarden van CUSTOMER. 
State weergeeft (uit de View Ridge-database). 
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29. 


30. 


31. 


32. 


33. 


34. 


35: 


36. 


BN 
A 


Schrijf een SQL-statement dat een view maakt die de waarden van CUSTOMER. 
State weergeeft. Verwijder alle eventuele duplicaten. 
Schrijf een SQL-statement dat een view maakt die LastName, City en State van 
CUSTOMER weergeeft. 

Schrijf een SQL-statement dat een view maakt die LastName, City en State van 
CUSTOMER weergeeft voor klanten uit Californië. 
Schrijf een SQL-statement voor het maken van een view die CUSTOMER. Last- 
Name en een berekend attribuut met de naam Location weergeeft. Location 
moet CUSTOMER.CITY en CUSTOMER.State met elkaar combineren in een 
indeling zoals ‘Chicago, IL. 

Schrijf een SQL-statement voor het maken van een view die de view weergeeft 
die je in je antwoord op vraag 25 hebt gemaakt, maar die alleen klanten uit 
Californië laat zien. 

Schrijf een SQL-statement voor het maken van een view die ARTIST.LastName, 
WORK.Title en WORK.Description weergeeft. 

Schrijf een SQL-statement voor het maken van een view die CUSTOMER. Last- 
Name, WORK.Title en ARTIST.LastName weergeeft voor alle aankopen door 
klanten. 

Schrijf een SQL-statement voor het maken van een view die NetProfit berekent 


(het verschil tussen SalesPrice en AskingPrice) voor elke aankoop door een 
klant. 


„ Schrijf een SQL-statement voor het maken van een view die de som van NetPro- 


fit berekent voor elke klant. 


. Schrijf een SQL-statement voor het maken van een view die de som van NetPro- 


fit berekent voor elke combinatie van een klant en een kunstenaar. 


. Beschrijf hoe views worden gebruikt voor het leveren van een indirecte verbin- 


ding tussen applicaties en tabellen. Waarom kan dat belangrijk zijn? 


. Leg uit hoe views gebruikt kunnen worden voor het verbeteren van de 


gegevensbeveiliging. 


. Leg uit hoe views gebruikt kunnen worden om meer triggerfunctionaliteit te 


bieden. 


„ Geef een voorbeeld van een view die duidelijk kan worden bijgewerkt. 
„ Geef een voorbeeld van een view die duidelijk niet kan worden bijgewerkt. 
„. Vat samen hoe in het algemeen kan worden bepaald of een view al dan niet kan 


worden bijgewerkt. 


„ Welke actie op een view is beslist niet toegestaan als er vereiste items ontbreken 


in deze view? 


. Leg uit wat het verschil is tussen een SQL-view en een externe view, zoals die 


beschreven is in hoofdstuk 2. Wanneer zijn deze hetzelfde? Wanneer zijn ze 
verschillend? 


„ Hoe is dat verschil uit je antwoord op vraag 46 te corrigeren? 
„ Wat is een trigger? 

. Wat zijn PL/SQL en T-SQL? 

„ Wat is de relatie tussen een trigger en een tabel of een view? 
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st. Noem negen mogelijke typen triggers. 

52. Leg in algemene termen uit hoe nieuwe en oude waarden beschikbaar worden 
gesteld aan triggers. 

53. Beschrijf vier mogelijke doeleinden voor triggers. 

54. Leg in algemene termen uit hoe je een trigger zou gebruiken voor het uitvoeren 
van een verwijdering uit WORK, gegeven de voor galerie View Ridge gedefini- 
eerde referential integrity-acties. 

55. Wat is een opgeslagen procedure? Waarin verschilt deze van een trigger? 

56. Vat samen op welke manier een opgeslagen procedure wordt aangeroepen. 

57. Vat samen wat de belangrijkste voordelen zijn van opgeslagen procedures. 


Projectvragen 


Gebruik het gegevensmodel en het gerelateerde databaseontwerp uit Figuur 7-36 
voor het beantwoorden van de volgende vragen. 


58. Beschrijf de relaties in termen van het type (identificerend of niet-identifice- 
rend) en de minimum- en maximumkardinaliteit. 

59. Leg voor elk van de foreign keys uit waarom deze nodig is. 

6o. Er worden alleen referential integrity-acties getoond voor de relatie COMPU- 
TER/TOEKENNING. Leg uit waarom D:C en U:C nodig zijn. 


WERKNEMER COMPUTER 


Naam GEBRUIKT Merk 

E-mail COMPUTER Model 

Afdeling tael ProcessorSnelheid 
Ü Werkgeheugen 


Schijfgeheugen 


WERKNEMER COMPUTER 


Y Serienummer: int NOT NULL 


Merk: char(18) NOT NULL 
Model: char(18) NULL 

ProcessorSnelheid: numeric(3,1) NOT NULL 
Werkgeheugen: char(10) NOT NULL 
Schijfgeheugen: char(10) NOT NULL 


GEBRUIKT D:C 
Naam: char(50) NOT NULL COMPUTER u:C 
E-mail: char(50) NOT NULL Croin 
Afdeling: char(35) NOT NULL 


Opmerking: de referential integrity h 
actions voor de EN 
WERKNEMER/TOEKENNING- TOEKENNING 


relatie is niet zichtbaar. \ Serienummer: NOT NULL (FK) 
WerknemerNummer: NOT NULL (FK) 
DatumToegekend: NOT NULL 
ToegekendDoor: NOT NULL 


Figuur 7-36 Gegevensmodel en gerelateerde databaseontwerp 
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61. Gebruik Figuur 6.23(b) als een sjabloon voor het definiëren van triggers voor het 
afdwingen van de vereiste child tussen WERKNEMER en TOEKENNING. Defi- 
nieer het doel van alle triggers die eventueel nodig zijn. Gebruik dezelfde stra- 
tegie als in dit hoofdstuk werd toegelicht voor de vereiste WERKNEMER-relatie 
(paragraaf 7.9.4). 

62. Leg de interactie uit tussen de trigger in je antwoord op vraag Gr en de D:C op 
COMPUTER/TOEKENNING. Wat wil je dat er gebeurt? Leg uit hoe je kunt uit- 
proberen of dat op de gewenste manier werkt. 

63. Schrijf CREATE TABLE-statements voor de tabellen uit Figuur 7-36. Schrijf 
CHECK-constraints om zeker te stellen dat Merk gelijk is aan Dell, IBM, Com- 
paq of Overig. Schrijf ook constraints om zeker te stellen dat ProcessorSnelheid 
tussen 0,8 en 5,0 ligt (deze eenheden zijn in gigahertz). 

64. Maak voorbeeldgegevens voor dit databaseontwerp. Je gegevens moeten min- 
stens zeven WERKNEMERS, drie COMPUTERs en zeven TOEKENNINGen 
omvatten. Zorg ervoor minstens één IBM-computer te hebben, minstens drie 
werknemers in de afdeling Boekhouding en minstens twee TOEKENNINGen 
met de waarde Jansen voor ToegekendDoor. 

65. Maak een WerknemerView die WERKNEMER.Naam en WERKNEMER AfF- 
deling weergeeft. Laat zien hoe je deze view gebruikt voor het weergeven van 
werknemers gesorteerd op naam. Laat de resultaten van deze view zien voor je 
voorbeeldgegevens. 

66. Maak een view BoekhoudingWerknemers die de view uit je antwoord op de vo- 
rige vraag gebruikt voor werknemers in de afdeling Boekhouding. 

67. Maak een view Computer die Serienummer, Merk en Model van COMPUTER 
weergeeft als een enkel attribuut ComputerType. Plaats een dubbele punt en 
een spatie tussen Merk en Model, zoals in Dell: 6200 Laptop. Laat de resultaten 
van deze view zien voor je voorbeeldgegevens. 

68. Maak een view ComputerMerken die het Merk en de gemiddelde Processor- 
Snelheid toont voor alle computers. Laat de resultaten van deze view zien voor 
je voorbeeldgegevens. 

69. Maak een view ComputerGebruikers die alle gegevens heeft van COMPUTER en 
TOEKENNING. Laat de resultaten van deze view zien voor je voorbeeldgegevens. 

7o. Gebruik de view uit je antwoord op de vorige vraag voor het maken van een an- 
dere view ComputersGebruiktDoorToegekendePersoon, die alle gegevens weer- 
geeft voor COMPUTER en TOEKENNING, gegroepeerd op ToegekendDoor. 
Laat de resultaten van deze view zien voor je voorbeeldgegevens. 

71. Gebruik de view die je Computers hebt genoemd voor het weergeven van Serie- 
nummer, ComputerType en Werknemernaam van de computers. 

72. Leg uit hoe je een aan TOEKENNING gekoppelde trigger zou gebruiken voor 
het opleggen van de beperking dat een werknemer minstens één computer 
moet hebben. Wat voor soort trigger zou je gebruiken? Beschrijf de logica van 
een dergelijke trigger. 
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Marcia’s Chemische Reiniging 


Stel dat je een database hebt ontworpen voor Marcia’s Chemische Reiniging, die de 
volgende tabellen omvat: 


DJ 


CUSTOMER (CustomerlD, FirstName, LastName, Phone, E-mail) 
INVOICE (InvoiceNumber, CustomerID, Dateln, DateOut, Subtotal, 
Tax, TotalAmount) 
INVOICE ITEM (InvoiceNumber, ItemNumber, Service, Quantity, 
UnitPrice, ExtendedPrice) 
SERVICE (Service, Description, UnitPrice) 


Geef NULL/NOT NULL-constraints voor alle tabelkolommen. 

Geef alternatieve sleutels, als die er zijn. 

Noem relaties, zoals die door de foreign keys worden geïmpliceerd, en geef de 
maximum- en de minimumkardinaliteit van elke relatie op. Rechtvaardig je 
keuzes. 

Leg uit hoe je de minimumkardinaliteiten uit je antwoord op vraag C afdwingt. 
Gebruik referential integrity-acties voor eventuele vereiste parents. Gebruik 
Figuur 6-23(b) als een sjabloon voor eventuele vereiste children. 

Schrijf CREATE TABLE-statements voor elk van de tabellen. Gebruik daar waar 
nodig je antwoorden op vraag A tot en met D voor. Stel de eerste waarde van 
CustomerID in op roo en vermeerder deze met 5. Gebruik FOREIGN KEY- 
constraints voor het maken van passende referential integrity constraints. Stel 
UPDATE- en DELETE-gedrag in, overeenkomstig de referential integrity acties 
die je ontworpen hebt. Stel de defaultwaarde van Quantity in op 1. Schrijf een 
constraint die bepaalt dat SERVICE. UnitPrice tussen 1,50 en 1o,oo moet liggen. 
Leg uit hoe je de data constraint zou afdwingen dat INVOICE_ITEM.Unit- 
Price gelijk moet zijn aan SERVICE.UnitPrice, als INVOICE_ITEM.Service = 
SERVICE.Service. 

Schrijf INSERT-statements voor het invoegen van minstens drie rijen in elke 
tabel. Gebruik de gegevens uit de tabellen aan het eind van hoofdstuk 2 als uit- 
gangspunt en voeg waar nodig gegevens toe. 

Schrijf een UPDATE-statement voor het wijzigen van waarden van SERVICE. 
Description van Suit-Mens in Mens’ Suit. 

Schrijf DELETE-statement(s) voor het verwijderen van een INVOICE en alle 
items in deze INVOICE. 

Maak een view met de naam InvoiceSummary die INVOICE.Date, INVOICE 
ITEM.Service en INVOICE ITEM.ExtendedPrice bevat. 

Maak een view met de naam CustomerlnvoiceSummary die CUSTOMER. 
FirstName, CUSTOMER.LastName, CUSTOMER.Phone, INVOICE.Date, IN- 
VOICE.SubTotal, INVOICE_ITEM.Service en INVOICE_ITEM.ExtendedPrice 
bevat. 
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Maak een view met de naam CustomerHistory die alle kolommen van Custo- 


merInvoiceSummary omvat en die de som en het gemiddelde berekent van 


INVOICE_ITEM.ExtendedPrice voor elke klant. Maak een view met de naam 
CustomerCheck, die CustomerHistory gebruikt en die alle eventuele klanten 
weergeeft voor wie de som van INVOICE ITEM.ExtendedPrice niet gelijk is aan 
INVOICE.SubTotal. 

Leg in algemene termen uit hoe je triggers gebruikt voor de acties voor het af- 
dwingen van de minimumkardinaliteit die voor je ontwerp nodig zijn. Je hoeft 
de triggers niet te schrijven. Je moet alleen opgeven welke triggers je nodig hebt 
en in algemene termen uitleggen wat hun logica is. 


Importbedrijf Morgan 


Stel dat je een database hebt ontworpen voor Importbedrijf Morgan, die de volgende 
tabellen omvat: 
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PURCHASE (PurchaselD, StoreName, Date, Description, Category, 
PriceUSD) 

SHIPMENT (ShipmentID, ShipperlD, ShipperInvoiceNumber, Origin, 
Destination, DepartureDate, ArrivalDate) 

SHIPMENT ITEM (ShipmentID, PurchaselD, InsuredValue) 

SHIPPER (ShipperID, ShipperName, Phone, Fax, E-mail, Contact 


STORE (StoreName, City, Country, Phone, Fax, E-mail, Contact 
I 


Moet STORE volgens jou een surrogate key hebben? Zo ja, maak deze en voer 
de nodige wijzigingen uit in je ontwerp. Zo niet, leg uit waarom niet en voer 
waar je denkt dat dit nodig is overige wijzigingen uit in STORE en de andere 
tabellen. 

Geef NULL/NOT NULL-constraints op voor alle tabelkolommen. 

Geef alternatieve sleutels op, als die er zijn. 

Noem relaties, zoals die door de foreign keys worden geïmpliceerd, en geef de 
maximum- en de minimumkardinaliteit van elke relatie op. Rechtvaardig je 
keuzes. 

Leg uit hoe je de minimumkardinaliteiten uit je antwoord op vraag D afdwingt. 
Gebruik referential integrity-acties voor eventuele vereiste parents. Gebruik 
Figuur 6-23(b) als een sjabloon voor eventuele vereiste children. 

Schrijf CREATE TABLE-statements voor elk van de tabellen. Gebruik daar waar 
nodig je antwoorden op vraag A tot en met E voor. Stel de eerste waarde van 
PurchaselD in op soo en vermeerder deze met 5. Stel de eerste waarde van 
ShipmentID in op roo. Gebruik FOREIGN KEY-constraints voor het maken van 
passende referential integrity constraints. Stel UPDATE- en DELETE-gedrag in, 
overeenkomstig de referential integrity-acties die je ontworpen hebt. Stel de 
defaultwaarde van Insured Value in op roo. Schrijf een constraint die STORE. 


M. 
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Country beperkt tot op zeven landen — je mag zelf kiezen in welke zeven landen 
je wilt kopen. 

Leg uit hoe je de regel afdwingt dat SHIPMENT_ITEM.InsuredValue minstens 
even groot moet zijn als PURCHASE.Price USD. 

Schrijf INSERT-statements voor het invoegen van minstens drie rijen in elke 
tabel. 

Schrijf een UPDATE-statement voor het wijzigen van waarden van STORE.City 
van New York City in NYC. 

Schrijf DELETE-statement(s) voor het verwijderen van een SHIPMENT en alle 
items in deze SHIPMENT. 

Maak een view met de naam PurchaseSummary die alleen PURCHASE. Date, 
PURCHASE.Description en PURCHASE.PriceU SD weergeeft. 

Maak een view met de naam StorePurchaseHistory, die STORE.StoreName, 
STORE.Phone, STORE.Contact, PURCHASE.Date, PURCHASE.Description 
en PURCHASE.PriceUSD weergeeft. 

Maak een view met de naam StoreHistory, die de som van de kolom PriceUSD 
van StorePurchaseHistory voor elke winkel berekent in een kolom met de naam 
TotalPurchases. 

Maak een view met de naam MajorSources, die StoreHistory gebruikt en 
die alleen die winkels selecteert die TotalPurchases hebben die groter zijn 
dan roo.ooo. 

Leg in algemene termen uit hoe je triggers gebruikt voor de acties voor het af- 
dwingen van de minimumkardinaliteit die voor je ontwerp nodig zijn. Je hoeft 
de triggers niet te schrijven. Je moet alleen opgeven welke triggers je nodig hebt 
en in algemene termen uitleggen wat hun logica is. 
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Hoofdstuk 8 
Databases herontwerpen 


Zoals je gezien hebt in hoofdstuk 1, ontstaan databases op drie manieren. Ze kunnen 
worden gemaakt op basis van bestaande gegevens, ze kunnen het resultaat zijn van 
het ontwikkelen van nieuwe systemen, of ze ontstaan door herontwerp van bestaande 
databases. We hebben de eerste twee manieren besproken in de vorige hoofdstukken. 
In dit hoofdstuk bespreken we de laatste manier: het herontwerp van een database. 

Om te beginnen bespreken we waarom het herontwerpen van een database nodig 
is en beschrijven we twee belangrijke SQl-statements: gecorreleerde subquery’s en 
EXISTS. Deze statements spelen een belangrijke rol in het analyseren van gegevens voor 
het herontwerpen. Bovendien zijn ze worden bruikbaar voor geavanceerde query’s. 
Daarna bespreken we een aantal veelvoorkomende taken die komen kijken bij het her- 
ontwerpen van databases. 
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8.1 _De noodzaak tot herontwerp van een database 


Je vraagt je misschien af: “Waar is herontwerp van een database goed voor? Waarom 
zouden we ooit een database moeten herontwerpen, als we die de eerste keer met- 
een goed hebben ontworpen?’ Er zijn twee antwoorden op deze vraag. Ten eerste is 
het niet makkelijk databases de eerste keer meteen goed te ontwerpen, vooral niet 
als het gaat om databases die resulteren uit de ontwikkeling van nieuwe systemen. 
De taken voor het opzetten van een goed datamodel en het omzetten daarvan in een 
goed databaseontwerp zijn moeilijk, zelfs als we alle eisen van de gebruikers weten. 
Deze taken zijn vooral voor grote databases erg ingewikkeld en er zijn misschien di- 
verse ontwikkelingsstadia nodig. Tijdens deze stadia moeten bepaalde aspecten van 
de database opnieuw worden ontworpen. Het is ook onvermijdelijk dat er vergissin- 
gen moeten worden gecorrigeerd. 

Het tweede antwoord op deze vraag is nog belangrijker. Denk eens even na over 
de relatie tussen informatiesystemen en de organisaties die daarvan gebruikmaken. 
Informatiesystemen en organisaties beïnvloeden elkaar niet alleen — ze creëren elkaar. 
Als er een nieuw informatiesysteem wordt geïnstalleerd, dan kunnen de gebruikers 
zich op nieuwe manieren gaan gedragen. Als ze dat doen, zullen ze wijzigingen 
in het informatiesysteem willen zien om aan hun nieuwe gedrag tegemoet te ko- 
men. Worden die wijzigingen uitgevoerd, dan kunnen de gebruikers zich opnieuw 
op nieuwe manieren gaan gedragen en zullen zij meer wijzigingen in het informa- 
tiesysteem vragen — enzovoort, in een eindeloze cirkel. 

Dit eindeloze proces betekent dat wijzigingen in een informatiesysteem geen on- 
gelukkige consequenties van een slechte implementatie zijn, maar eerder een na- 
tuurlijk resultaat van het gebruik van een informatiesysteem. De noodzaak voor het 
wijzigen van een informatiesysteem verdwijnt dus nooit — deze noodzaak kan (en 
mag) niet voorkomen worden door de eisen beter te definiëren, door het eerste ont- 
werp beter te doen, door beter te implementeren of door wat dan ook. Verandering 
hoort gewoon bij het gebruik van informatiesystemen. We moeten er dan ook reke: 
ning mee houden in de planning. Dat betekent in de context van de databaseverwer- 
king dat we moeten weten hoe we databases herontwerpen. 


8.2 SQL-statements voor functionele afhankelijkheden 


Het herontwerpen van een database is niet echt moeilijk als de database geen gege- 
vens bevat. De echte moeilijkheden ontstaan als we een database moeten veranderen 
die gegevens bevat, waarbij de wijzigingen zo weinig mogelijk invloed mogen heb- 
ben op die gegevens. Het is onacceptabel gebruikers te vertellen dat hun systeem nu 
werkt zoals ze dat willen, maar dat al hun gegevens verloren zijn gegaan tijdens het 
uitvoeren van deze wijzigingen. 

Meestal moeten we weten of bepaalde omstandigheden of aannames geldig zijn 
in de gegevens, voordat we een wijziging kunnen uitvoeren. De gebruikers zeggen 
bijvoorbeeld dat Afdelingstelefoonnummer functioneel wordt bepaald door Afde- 
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ling, maar we weten misschien niet of deze functionele afhankelijkheid goed in alle 
gegevens is gerepresenteerd. 

Je zult je uit hoofdstuk 3 herinneren dat elke waarde van Afdeling aan dezelfde 
waarde van Afdelingstelefoonnummer gekoppeld moet worden als Afdelingstele- 
foonnummer door Afdeling wordt bepaald. Heeft de afdeling Boekhouding bijvoor- 
beeld een rij met Afdelingstelefoonnummer 834-1100, dan moet deze waarde in elke 
rij van deze afdeling staan. Heeft de afdeling Financiën een rij met een Afdelingste- 
lefoonnummer 834-2100, dan moet deze waarde in elk van de rijen van deze afde- 
ling staan. 

Figuur 8-1 toont gegevens die deze aanname overtreden. Het Afdelingstelefoon- 
nummer voor Boekhouding in de derde rij verschilt van die in de andere rijen — er 
staat een nul te veel. Iemand heeft waarschijnlijk een typefout gemaakt tijdens het 
invoeren van Afdelingstelefoonnummer — dergelijke fouten komen veel voor. 


K Werknemernummer | __Naam ke Afdeling Afdelingstelefoonnummer 

| ___100 ì Jansen Boekhouding 834-1100 a 
200 | Groen | Financiën Í 834-2100 
____300 | Abelse _| Financiën 834-21000 
400 __|Park 5 Boekhouding 834-1100 
men 500 Kowalski ___ Productie 834-4100 
je 600 ‚Lopez | Financiën I 834-2100 
___700 Groen _| Boekhouding IE 834-1100 


Figuur 8-1 Een tabel die een aangenomen constraint schendt 


We moeten al die onvolkomenheden opzoeken en corrigeren voordat we een wijzi- 
ging in de database kunnen uitvoeren. We kunnen bij de kleine tabel in Figuur 8-1 
gewoon de gegevens bekijken, maar wat moeten we doen als de tabel WERKNEMER 
vierduizend rijen heeft? Er zijn twee SQL-statements die daar heel nuttig voor kun- 
nen zijn: gecorreleerde subquery’s en hun neefje EXISTS/NOT EXISTS. We zullen 
ze allebei bekijken. 


8.2.1 Gecorreleerde subquery’s 

Gecorreleerde subquery’s lijken op het eerste gezicht veel op de subquery’s die we 
in hoofdstuk 2 bespraken, maar verschillen daar in werkelijkheid sterk van. Kijk ter 
illustratie van het verschil eens naar de volgende subquery, die op de subquery’s uit 
hoofdstuk 6 lijkt: 


SELECT A.FirstName, A.LastName 
FROM ARTIST AS A 
WHERE A.ArtistID IN 
(SELECT W.ArtistID 
FROM WORK AS W 
WHERE W.Title ='Blue Interior’); 
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Het DBMS kan dergelijke subquery’s van onder naar boven doorwerken. Dat wil 
zeggen: het DBMS zoekt eerst alle waarden van ArtistID in WORK waarvoor de titel 
‘Blue Interior’ is en verwerkt dan de bovenste query voor deze verzameling waarden. 
Het is niet nodig tussen de beide SELECT-statements heen en weer te gaan. Het re- 
sultaat is, zoals we al verwachtten, de artiest Tobey. 


8.2.2 Meer rijen zoeken van een bepaalde titel 

Laten we nu eens een gecorreleerde subquery bekijken. Stel dat iemand bij galerie 
View Ridge voorstelt dat de kolom Title van WORK een alternatieve sleutel is. Je kunt 
in de gegevens in Figuur 7-13(d) zien dat er maar één kopie is van ‘Blue Interior’, 
maar dat er twee of meer kopieën zijn van andere titels, zoals ‘Surf and Bird’. Title 
kan dus geen alternatieve sleutel zijn. 

Dat is echter veel moeilijker te bepalen als de tabel WORK tienduizend of meer 
rijen heeft. In dat geval hebben we een query nodig op de tabel WORK, om Title en 
Copy weer te geven van alle werken die dezelfde titel hebben. 

Als iemand ons zou vragen een programma te schrijven voor het uitvoeren van 
die query, dan zouden we als volgt denken: neem de waarde van Title uit de eerste 
rij in WORK en vergelijk die met alle andere rijen in de tabel. Vinden we een rij met 
dezelfde titel als in de eerste rij, dan weten we dat er duplicaten zijn. We drukken 
dan Title en Copy van het eerste werk af. We gaan door met het zoeken naar gedupli- 
ceerde titelwaarden tot we het eind van de tabel WORK bereiken. 

Daarna nemen we de waarde van Title in de tweede rij en vergelijken die met alle 
rijen in de tabel WORK, waarbij we ook weer Title en Copy afdrukken van alle even- 


tuele gedupliceerde werken. We gaan op die manier door tot alle rijen van de tabel 
WORK zijn onderzocht. 


8.2.3 Een gecorreleerde subquery die rijen vindt met dezelfde titel 
De volgende gecorreleerde subquery doet precies wat hiervoor beschreven is: 


SELECT Wl.Title, Wl.Copy 


FROM WORK AS WI 
WHERE WI.Title IN 
(SELECT W2.Title 
FROM WORK AS W2 
WHERE Wl.Title = W2.Title 
AND Wl.WorkID <> W2.WorkID); 


Het resultaat van deze query is (voor de gegevens uit Figuur 7-13): 


Mystic Fabric 99/135 
Mystic Fabric 105/135 


Figuur 8-2 Resultaat gecorreleerde subquery met de gegevens uit Figuur 7-13 
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Deze query lijkt veel op een gewone subquery. Het zal je dus misschien verrassen te 
horen dat deze sterk van de vorige query verschilt. Ze lijken alleen oppervlakkig op 
elkaar. 

Kijk, voordat we uitleggen waarom, eerst eens naar de notatie van de gecorreleer- 
de subquery: de tabel WORK wordt zowel in het bovenste als het onderste SELECT- 
statement gebruikt. Deze tabel krijgt in het bovenste statement de alias Wr en in het 
onderste statement de alias Wa. 

Het gebruik van deze notatie betekent in feite dat de query zich gedraagt alsof we 
twee kopieën hebben gemaakt van de tabel WORK, met de namen Wren Wa. Daar- 
om vergelijken de laatste twee regels van de gecorreleerde subquery waarden uit de 
kopie Wr van WORK met waarden uit de kopie Wa. 


8.2.4 Het verschil tussen gewone en gecorreleerde subquery’s 

Denk er nu eens over na wat deze subquery zo anders maakt. Het DBMS kan de on- 
derste SELECT, anders dan bij een gewone subquery, niet op zichzelf uitvoeren. Het 
kan niet een verzameling titels ophalen en deze verzameling dan gebruiken voor het 
uitvoeren van de bovenste query. De reden daarvoor zit in de onderste twee regels 
van de query: 


WHERE WI.Title = W2.Title 
AND Wl.WorkID <> W2.WorkID 


Deze uitdrukkingen vergelijken W1.Title (uit het bovenste SELECT-statement) met 
W2.Title (uit het onderste SELECT-statement). Hetzelfde geldt voor Wr.WorkID en 
W2.WorkID. Het DBMS kan het subquerydeel daarom niet onafhankelijk van de bo- 
venste SELECT uitvoeren. 

In plaats daarvan moet het DBMS dit statement uitvoeren als een subquery die 
in de hoofdquery is genest. De logica zit zo in elkaar: neem de eerste rij van Wi. Ge- 
bruik deze rij voor het evalueren van de tweede query. Vergelijk Wr.Title en W1. Work 
daartoe met W2.Title en Wa. Work uit elke rij van Wa. Lever de waarde van Wa.Title 
aan de bovenste query als de titels identiek zijn maar de waarden van WorkID niet 
hetzelfde zijn. Doe dat voor elke rij in Wa. 

Ga naar de tweede rij in Wr als alle rijen van Wa zijn verwerkt voor deze rij en 
vergelijk deze met alle rijen in W2. Ga op die manier door tot alle rijen van Wr zijn 
vergeleken met alle rijen van Wa. 

Mocht dat je nog niet helemaal duidelijk zijn, noteer dan twee kopieën van de 
gegevens in WORK uit Figuur 7.13 op een vel papier. Label de ene kopie Wr en de 
andere W2 en werk de beschreven logica door. Je zult aan de hand hiervan zien dat 
gecorreleerde subquery’s altijd geneste verwerking vereisen. 
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8.2.5 Een veelvoorkomende fout 
Pas er overigens voor op de volgende veelvoorkomende fout te maken: 


SELECT WI.Title, Wl.Copy 


FROM WORK AS WI 
WHERE Wl.WorkID IN 
GSELEECT W2.WorkID 
FROM WORK AS W2 
WHERE Wl.Title = W2.Title 
AND Wl.WworkID <> W2.WorkID); 


De logica lijkt te kloppen, maar dat is niet zo. Deze query zal nooit een rij weergeven, 
ongeacht welke gegevens er worden verwerkt. Probeer eens uit te zoeken waarom 
dat zo is, voordat je verder leest. 

De onderste query zal inderdaad alle rijen vinden met dezelfde titel, maar ver- 
schillende WorkIDs. Als er zo'n rij wordt gevonden, dan zal de onderste query 
W2.WorkID van deze rij leveren. Die waarde zal dan echter vergeleken worden met 
W1.WorkID. Deze twee waarden zullen altijd verschillend zijn, vanwege de voorwaarde 
Wi. WorkID <> Wa.WorkID. Er zullen geen rijen worden geleverd, omdat de waar- 


den van twee ongelijke WorklDs worden gebruikt in de IN in plaats van de waarden 
van de twee identieke Title's. 


8.2.6 Gecorreleerde subquery’s en functionele afhankelijkheden 
Gecorreleerde subquery’s kunnen met succes gebruikt worden tijdens het herontwer- 
pen van een database. Zoals gezegd is een toepassing van gecorreleerde subquery’s 
het verifiëren van functionele afhankelijkheden. Stel dat we WERKNEMER-gege- 
vens hebben zoals die in Figuur 8-1 en dat we willen weten of deze gegevens voldoen 
aan de functionele afhankelijkheid Afdeling — Afdelingstelefoonnummer. Is dat het 
geval, dan zal elke gegeven waarde van Afdeling in de tabel altijd zijn gekoppeld aan 
dezelfde waarde van Afdelingstelefoonnummer. 


De volgende gecorreleerde subquery zoekt alle rijen die niet aan deze aanname 
voldoen: 


SELECT Wl.Afdeling, Wl.Afdelingstelefoonnummer 


FROM WERKNEMER AS WI 
WHERE Wl.Afdeling IN 
(SELECT W2.Afdel ing 
FROM WERKNEMER AS W2 
WHERE Wl.Afdeling = W2.Afdeling 
AND Wl.Afdelingstelefoonnummer <5 


W2.Afdelingstelefoonnummer) ; 


Het resultaat is (voor de gegevens uit Figuur 8-1): 
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[Boekhouding | = 834-2100 | 
LBoekhouding | 834-21000 | 


Figuur 8-3 Resultaat gecorreleerde subquery voor de gegevens uit Figuur 8-1 


Rijen die de functionele afhankelijkheid schenden, zijn snel en makkelijk te vinden 
met een dergelijke query. 


8.2.7 EXISTS en NOT EXISTS 
EXISTS en NOT EXISTS zijn ook een soort gecorreleerde subquery. We kunnen de 
vorige gecorreleerde subquery als volgt schrijven met EXISTS: 


SELECT Wl.Afdeling, Wl.Afdelingstelefoonnummer 
FROM WERKNEMER AS WI 
WHERE EXISTS 
(SELECT * 
FROM WERKNEMER AS W2 
WHERE Wl.Afdeling = W2.Afdeling 
AND Wl.l Afdelingstelefoonnummer <> 


W2. Afdelingstelefoonnummer); 


De verwerking van de SELECT-statements is genest, omdat EXISTS een soort ge- 
correleerde subquery is. De eerste rij van Wr wordt in de subquery ingevoerd. De 
EXISTS is waar en Afdeling en Afdelingstelefoonnummer voor de eerste rij worden 
geselecteerd als de subquery een rij in Wa vindt waarvoor de afdelingsnamen dezelf: 
de zijn en de telefoonnummers verschillen. Daarna wordt de tweede rij van Wr in de 
subquery ingevoerd, de SELECT wordt verwerkt en de EXISTS wordt geëvalueerd. 
Als deze waar is, dan worden de Afdeling en het Afdelingstelefoonnummer van de 
tweede rij geselecteerd. Dit proces wordt herhaald voor elke rij in Wr. 

Het sleutelwoord EXISTS zal waar zijn als er een rij is in de subquery die aan de 
voorwaarde voldoet. 


8.2.8 NOT EXISTS gebruiken in een dubbele ontkenning 
Het sleutelwoord NOT EXISTS zal alleen waar zijn als elke rij in de subquery niet aan 
de voorwaarde voldoet. 

Dat betekent dat NOT EXISTS kan worden gebruikt om rijen te vinden die niet 
niet aan de voorwaarde voldoen, door het sleutelwoord tweemaal te gebruiken. De lo- 
gica van de dubbele ontkenning betekent dat een rij die niet (niet overeenkomt met 
welke rij dan ook) overeen zal komen met elke rij. 

Stel bijvoorbeeld dat de gebruikers bij View Ridge de namen willen weten van die 
kunstenaars in wie alle klanten zijn geïnteresseerd. We gaan dan als volgt te werk: 
we produceren om te beginnen de verzameling van alle klanten die in een bepaalde 
kunstenaar zijn geïnteresseerd. We nemen dan het complement van deze verzame- 
ling — dus alle klanten die niet in deze kunstenaar zijn geïnteresseerd. Is dat comple- 
ment leeg, dan zijn alle klanten geïnteresseerd in deze kunstenaar. 
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Opmerking 

Voordat we verdergaan, willen we nog een specifiek NOT EXISTS-patroon noemen dat iedereen die met 
sQL werkt wel in de een of andere vorm zal kennen. Dit patroon wordt vaak bij sollicitatiegesprekken 
gebruikt om de kennis van SQL te testen en het kan, zoals je in het laatste deel van dit hoofdstuk 

zult zien, nuttig zijn voor het bepalen van de wenselijkheid van bepaalde mogelijkheden voor het 
herontwerpen van een database. Dit voorbeeld vereist weliswaar wat studie, maar het is zeker de moeite 
waard het te begrijpen. 


8.2.9 De dubbele NOT EXISTS 


Het volgende SQL-statement implementeert de zojuist beschreven strategie: 


SELECT A.FirstName, A.LastName 
FROM ARTIST AS A 
WHERE NOT EXISTS 

(SELECT C.CustomerID 

FROM CUSTOMER AS C 


WHERE NOT EXISTS 
(SELECT CAI.CustomerID 
FROM CUSTOMER ARTIST INT AS CAI 
WHERE C.CustomerID= CAI.CustomerID 
AND A.ArtistID = CAI.ArtistID)); 


De onderste SELECT zoekt alle klanten die geïnteresseerd zijn in een bepaalde kun- 
stenaar. Denk er tijdens het lezen van deze SELECT (de laatste in de query) aan dat 
het een gecorreleerde subquery is — deze SELECT is genest binnen de query voor 
CUSTOMER, die genest is binnen de query voor ARTIST. C.CustomerID is afkom- 
stig uit de SELECT voor CUSTOMER in het midden en A.ArtistID is afkomstig uit 
de SELECT voor ARTIST bovenaan. 

De NOT EXISTS in de zesde regel van de query zal nu alle klanten vinden die 
niet in de gegeven kunstenaar zijn geïnteresseerd. Zijn alle klanten in de gegeven 
kunstenaar geïnteresseerd, dan zal het resultaat van de middelste SELECT null zijn. 
De derde regel van de query is in dat geval waar en de naam van de kunstenaar zal 
geleverd worden — precies zoals de bedoeling was. 

Denk nu eens na over wat er gebeurt voor kunstenaars die niet aan deze query 
voldoen. Stel dat elke klant behalve Tiffany Twilight is geïnteresseerd in de kunste- 
naar Miro. (Dat was niet het geval in de gegevens in Figuur 7.13, maar neem aan dat 
dit waar is.) De onderste SELECT zal nu alle klanten ophalen, behalve Tiffany Twi- 
light, als de rij van Miro wordt verwerkt in deze query. De NOT EXISTS in de zesde 
regel van de query zal er nu voor zorgen dat de middelste SELECT de CustomerlD 
van Tiffany Twilight levert (want haar rij is de enige die niet in de onderste SELECT 
voorkomt). De NOT EXISTS in de bovenste SELECT zal nu onwaar zijn, omdat de 
middelste SELECT een resultaat levert en de naam Miro zal worden opgenomen 
in de uitvoer van de query. Dat klopt ook, want er is een klant die niet in Miro is 


geïnteresseerd. 
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Neem de tijd dit patroon eens rustig te bestuderen. Het is een beroemd patroon, dat 
je zeker in de een of andere vorm zult tegenkomen als je later met databases zult 
werken. 


8.3 De bestaande database analyseren 


Voorat we verdergaan met het bespreken van het herontwerpen van databases, gaan 
we eerst kort in op wat deze taak inhoudt voor een echt bedrijf dat voor zijn werk- 
zaamheden afhankelijk is van de database. Stel dat je voor een bedrijf zoals Amazon. 
com werkt en dat je bent gevraagd een belangrijke database te herontwerpen — laten 
we zeggen dat je de primaire sleutel moet wijzigen van de tabel met leveranciers. 

Je vraagt je om te beginnen misschien af waarom ze dat zouden willen doen. Het 
kan zijn dat Amazon.com in zijn begintijd, toen het alleen nog boeken verkocht, 
bedrijfsnamen gebruikte als leveranciers. Maar bedrijfsnamen voldoen niet meer, 
sinds Amazon.com begonnen is met het verkopen van allerlei andere soorten pro- 
ducten. Of misschien zijn er te veel duplicaten en is besloten op een door Amazon. 
com gemaakte Leverancier D over te stappen. 

Maar wat houdt het omschakelen van primaire sleutels nu in? Wat moeten we 
nog meer doen, naast het toevoegen van nieuwe gegevens aan de juiste rijen? Werd 
de oude primaire sleutel als een externe sleutel gebruikt, dan moeten alle externe 
sleutels natuurlijk ook worden veranderd. We moeten dus alle relaties kennen waar 
de oude primaire sleutel in werd gebruikt. En hoe staat het met views? Als er views 
zijn die gebruikmaken van de oude primaire sleutel, dan moeten die ook worden ver- 
anderd. Dan zijn er nog de triggers en opgeslagen procedures: gebruiken sommige 
daarvan de oude primaire sleutel? Om maar niet te spreken van een bestaande appli- 
catiecode die niet meer werkt als de oude sleutel wordt verwijderd. 

Laten we er nu helemaal een nachtmerrie van maken: stel je voor dat je de wijzi- 
gingen deels hebt uitgevoerd en dat er iets misgaat? Je komt onverwachte gegevens 
tegen en je krijgt foutmeldingen van het DBMS als je probeert de nieuwe primaire 
sleutel toe te voegen. Amazon.com kan zijn website niet wijzigen en melden: ‘Sorry, 
onze database doet het niet. Kom alstublieft morgen terug (we hopen dat het dan 
weer werkt)’ 

Deze nachtmerrie brengt ons bij allerlei onderwerpen, waarvan de meeste te ma- 
ken hebben met systeemanalyse en -ontwerp. Maar er worden ook drie principes 
duidelijk die het verwerken van databases betreffen. Ten eerste moeten we de hui- 
dige structuur en inhoud van een database goed begrijpen en we moeten weten wat 
waarvan afhankelijk is, voordat we proberen wijzigingen aan te brengen in de struc- 
tuur. Ten tweede moeten we alle wijzigingen uitproberen op een proefdatabase met 
een realistische grootte, die alle belangrijke gegevens voor het testen bevat, voor- 
dat we enigerlei structurele wijzigingen aanbrengen in een operationele database. 
Ten slotte moeten we, als dat ook maar enigszins mogelijk is, een volledige back- 
up maken van de operationele database, voordat we beginnen met het aanbrengen 
van wijzigingen in de structuur. Mocht het helemaal mislopen, dan kunnen we de 
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back-up gebruiken voor het herstellen van de database, terwijl de problemen worden 
opgelost. We zullen elk van deze belangrijke onderwerpen hier bespreken. 


8.3.1 Reverse engineering 
Reverse engineering is het proces van het lezen van een databaseschema en het pro- 
duceren van een datamodel op basis van dat schema. 

Het geproduceerde datamodel is niet echt een logisch model. Er zullen entiteiten 
worden gegenereerd voor elke tabel, waaronder entiteiten voor intersectietabellen 
die geen gegevens bevatten die geen sleutels zijn, en die helemaal niet in een logisch 
model horen voor te komen. Het door reverse engineering geproduceerde model is 
een apart iets — een tabel/relatiediagram dat op een entiteit-relatiemodel lijkt. We 
noemen het in dit boek een RE(reverse engineered)-datamodel. 


CUSTOMER_ARTIST_INT 


CUSTOMER 


[PK | customerlD 


LastName 
FirstName 
Street 

City 

State 
ZipPostalCode 
Country 
AreaCode 
PhoneNumber 
Email 


FirstName 
Nationality 
DateOfBirth 

DateDeceased 


DateAcquired 
AcquisitlonPrice 
AskingPrice 
DateSold 
SalesPrice 
WorklD 
CustomerlD 


Figuur 8-4 Reverse engineered datamodel 


Figuur 8-4 laat een RE-datamodel zien dat door Microsoft Visio 2007 is gemaakt 
op basis van een SQL Server 2008 Express-versie van de View Ridge-database uit 
hoofdstuk 6. Merk op dat dit meer het ontwerp is van een fysieke database dan van 
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een logisch datamodel. We maken gebruik van Microsoft Visio vanwege de grote be- 
schikbaarheid. Dat betekent wel dat we moeten werken met de niet-standaard nota- 
tie van Visio. Merk op dat Visio een pijl gebruikt om een relatie aan te geven van de 
child naar de parent. Visio slaat kardinaliteiten op als eigenschappen van de relatie 
maar laat ze niet zien, zoals wij dat wel doen met behulp van kraaienpootnotatie. 

Sommige datamodelleringsproducten halen naast tabellen en views ook con- 
straints, triggers en opgeslagen procedures uit de database op. Deze dingen worden 
niet geïnterpreteerd, maar de tekst ervan wordt in het datamodel geïmporteerd — 
sommige producten geven ook aan welke relatie deze tekst heeft tot dingen waarnaar 
de tekst verwijst. Het opnieuw ontwerpen van constraints, triggers en opgeslagen 
procedures valt buiten deze bespreking. Je moet je echter realiseren dat ze ook deel 
uitmaken van de database en ook opnieuw moeten worden ontworpen. 


8.3.2 Dependency-graaf 
Voordat je databasestructuren gaat wijzigen, is het uitermate belangrijk dat je inzicht 
hebt in de onderlinge afhankelijkheden. Welke wijzigingen hebben waar invloed op? 
Neem bijvoorbeeld het wijzigen van de naam van een tabel. Waar wordt die naam 
gebruikt? In welke triggers? In welke opgeslagen procedures? In welke relaties? Van- 
wege de noodzaak de afhankelijkheden te kennen, beginnen veel projecten voor het 
herontwerpen van databases met het maken van een dependency-graaf. 

De term graaf is afkomstig uit een tak van de wiskunde die grafentheorie heet. 
Dependency-grafen zijn grafische weergaven die bestaan uit knooppunten en lijnen 
die deze knooppunten met elkaar verbinden. 


TRANS_CheckSalesPrice 


ARTIST 


CUSTOMER 


TRANS_AskingPricelnitialValue 


ArtistWorkNetView 


(] Tabel 
m View 
me Trigger 


ArtistWorkTotalNetView 


Figuur 8-5 Voorbeeld van een dependency-graaf (gedeelte) 
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Figuur 8-5 toont een gedeelte van een dependency-graaf, gebaseerd op het RE-data- 
model uit de vorige paragraaf. Hoewel dit maar een deeldiagram is, maakt het toch al 
duidelijk hoe ingewikkeld de afhankelijkheden zijn tussen databaseconstructies. Je 
kunt bijvoorbeeld zien dat voorzichtigheid bij wijzigingen in de tabel TRANS essen- 
tieel is. De consequenties van een dergelijke wijziging moeten worden beoordeeld 
met betrekking tot twee relaties, drie triggers en drie views. 


8.3.3 Back-ups van databases en testdatabases 

Een database kan potentieel zwaar beschadigd raken tijdens het herontwerpen. 
Daarom moet een volledige back-up van de operationele database worden gemaakt, 
voordat er enigerlei wijzigingen worden uitgevoerd. Het is ook van essentieel belang 
dat alle voorgestelde wijzigingen grondig worden getest. Structurele veranderingen 
moeten niet alleen met succes verlopen, maar triggers, opgeslagen procedures en 
applicaties moeten ook op de juiste manier werken met de herziene database. 

Er worden normaliter minstens drie verschillende kopieën van het database- 
schema gebruikt tijdens het proces van het herontwerpen. Een daarvan is een kleine 
testdatabase, die kan worden gebruikt voor de eerste tests. De tweede is een grotere 
testdatabase — die zelfs een volledige kopie van de operationele database kan zijn — 
die wordt gebruikt voor het uitvoeren van secundaire tests. Ten slotte is er nog de 
operationele database. 

Er moet een manier worden ontwikkeld om alle testdatabases in hun originele 
toestand te kunnen herstellen tijdens het testproces. De tests kunnen dan zo nodig 
opnieuw worden uitgevoerd vanaf hetzelfde beginpunt. Afhankelijk van de voorzie- 
ningen van het DBMS worden er back-up en recovery of andere voorzieningen ge- 
bruikt voor het herstellen van de database na een test. 

Het zal duidelijk zijn dat bedrijven met heel grote databases geen testdatabase 
kunnen hebben die een kopie van de operationele database is. In plaats daarvan 
moeten er kleinere testdatabases worden gemaakt, die echter alle belangrijke gege- 
venskenmerken van de operationele database moeten hebben — want anders leveren 
ze geen realistische testomgeving. Het maken van dergelijke testdatabases is een 
moeilijke en ingewikkelde taak — er zijn daarom veel interessante carrièremogelijk- 
heden voor het ontwikkelen van testdatabases en testsuites voor databases. 

Het zal bij organisaties met zeer grote databases ten slotte misschien niet moge- 
lijk zijn een volledige kopie van de operationele database te maken voordat wijzigin- 
gen in de structuur worden aangebracht. De database wordt dan in stukken verdeeld, 
waarna een back-up van een stuk wordt gemaakt en de wijzigingen in dat stuk wor- 
den uitgevoerd. Daarna komt het volgende stuk aan de beurt, enzovoort. Dat is een 
erg moeilijke taak die veel kennis en expertise vraagt en waar weken of maanden van 
planning voor nodig zijn. 


8.4 Namen en kolommen van tabellen veranderen 


We behandelen hier het wijzigen van tabellen en hun kolommen, waarvoor we al- 
leen SQL-g2-statements gebruiken. Veel DBMS-producten bieden ook andere 
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voorzieningen dan SQL voor het wijzigen van de structuur. Sommige producten 
bieden bijvoorbeeld grafische ontwerpprogramma’s die dit proces vereenvoudigen. 
Dergelijke kenmerken zijn echter niet gestandaardiseerd en je moet er niet van af- 
hankelijk zijn. De statements in dit hoofdstuk zullen met elk hoogwaardig DBMS- 
product werken, en de meeste zullen ook met Access werken. 


8.4.1 Tabelnamen veranderen 

Het wijzigen van de naam van een tabel lijkt op het eerste gezicht een onschuldige 
en eenvoudige bewerking. Als je nog eens naar Figuur 8-5 kijkt, zul je echter zien dat 
een dergelijke wijziging meer consequenties heeft dan je misschien zou denken. Als 
je de naam van de tabel WORK bijvoorbeeld in WORK_VERSION2 wilt veranderen, 
dan moeten daar diverse dingen voor gedaan worden. De constraint die de relatie 
van WORK naar TRANS definieert, moet worden gewijzigd. De view ArtistWorkNet- 
View moet worden geherdefinieerd en daarna moeten de triggers TRANS_Check- 
SalesPrice worden herschreven om de nieuwe naam te gebruiken. 

Er bestaat bovendien geen SQL-opdracht voor het wijzigen van de naam van een 
tabel. Je moet de tabel in plaats daarvan opnieuw maken met de nieuwe naam en 
vervolgens de oude tabel verwijderen. Die eis suggereert echter een goede strategie 
voor het wijzigen van tabelnamen. Maak eerst de nieuwe tabel met alle bijbehorende 
structuren. Verwijder de oude tabel als alles met de nieuwe tabel werkt. Is de tabel 
waarvan de naam moet worden veranderd te groot om te kopiëren, dan zul je een 
andere strategie moeten gebruiken. Dergelijke strategieën vallen echter buiten het 
kader van dit hoofdstuk. 

Deze strategie heeft echter een ernstig probleem. Work[D is een surrogaatsleu- 
tel. Zodra we de nieuwe tabel maken, zal het DBMS nieuwe waarden van WorkID in 
deze tabel maken. De nieuwe waarden zullen niet noodzakelijkerwijs overeenkomen 
met de waarden in de oude tabel, wat betekent dat er verkeerde waarden zullen voor- 
komen in de externe sleutel TRANS.WorkID. De makkelijkste manier om dat pro- 
bleem op te lossen, is door eerst de nieuwe versie van de tabel WORK te maken en 
WorkID niet als een surrogaatsleutel te definiëren. Vul daarna de huidige waarden 
van WORK in de nieuwe tabel in, inclusief de huidige waarden van Work[D. Veran- 
der vervolgens WorkID in een surrogaatsleutel. 

We beginnen met het maken van de tabel door het statement CREATE TABLE 
WORK _VERSIONz2 aan het DBMS door te geven. We definiëren WorkID als een 
integer, maar niet als een surrogaatsleutel. We moeten de WORK-constraints ook 
nieuwe namen geven. De oude constraints blijven bestaan en het DBMS zal een 
foutmelding over gedupliceerde constraints leveren als er geen nieuwe namen wor- 
den gebruikt wanneer de CREATE TABLE-statements worden verwerkt. Een voor- 
beeld van nieuwe namen voor de constraints is: 


CONSTRAINT WorkV2PK PRIMARY KEY (WorkID), 

CONSTRAINT WorkV2AK1 UNIQUE (Title, Copy), 

CONSTRAINT ArtíistV2FK FOREIGN KEY(ArtistID) 
REFERENCES ARTIST(ArtistID) 
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ON DELETE NO ACTION 
ON UPDATE NO ACTION 


Kopieer vervolgens de gegevens naar de nieuwe tabel met de volgende 
SQL-opdracht: 


INSERT INTO WORK VERSION2 (WorkID, Copy, Title, Medium, 
Description, ArtistID) 
SELECT (WorkID, Copy, Title, Medium, Description, ArtistID) 
FROM WORK; 


Verander nu de tabel WORK _VERSION2 door van WorkID een surrogaatsleutel te 
maken. In SQL Server kun je dat het makkelijkst doen door het grafische tabelont- 
werpvenster te openen en WordID te herdefiniëren als een IDENTITY-kolom. Er is 
geen standaard SQL voor het uitvoeren van deze wijziging. Stel de property Identity 
Seed in op de waarde 5oo en SQL Server zal de volgende nieuwe waarde van WorkID 
instellen op de grootste waarde die in WorkID voorkomt, plus 1. 
We moeten nu alleen nog de twee triggers definiëren. Dat kan door de tekst van 
de oude triggers te kopiëren en de naam WORK in WORK_VERSIONa te wijzigen. 
Nu moeten er testsuites worden uitgevoerd op de database om te verifiëren dat 
alle wijzigingen goed zijn uitgevoerd. Daarna kunnen de opgeslagen procedures en 
applicaties die WORK gebruiken, worden aangepast om met de nieuwe tabelnaam 


te werken.' Als alles klopt, kunnen de foreign key constraint WorkFK en de tabel 
WORK worden verwijderd met: 


ALTER TABLE TRANS DROP CONSTRAINT TransactionWorkFK; 
DROP TABLE WORK: 


De constraint TransactionWorkFK kan daarna weer aan TRANS worden toegevoegd 
door de nieuwe naam voor de tabel WORK te gebruiken: 


ALTER TABLE TRANS ADD CONSTRAINT TransactionWorkFK 
FOREIGN KEY(WorkID) REFERENCES WORK VERSION2 (WorkID) 
ON UPDATE NO ACTION 
ON DELETE NO ACTION; 


Het is duidelijk dat het veranderen van de naam van een tabel ingewikkelder is dan 
je op het eerste gezicht zou denken. Je ziet nu waarom bij sommige organisaties 


1_ Timing is hier van belang. De tabel WORK VERSION2 wordt gemaakt op basis van WORK. Zou- 
den triggers, opgeslagen procedures en toepassingen WORK blijven gebruiken terwijl WORK_ 
VERSION2 wordt geverifieerd, dan zal WORK VERSION2 niet meer up-to-date zijn. Er zal dan 
actie moeten worden ondernomen om WORK-_VERSION2 bij te werken, voordat de opgeslagen 
procedures en toepassingen overgezet kunnen worden naar deze tabel. 
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geen enkele programmeur of gebruiker ooit de echte naam van een tabel mag ge- 
bruiken. In plaats daarvan worden views gebruikt die als aliassen voor de tabellen 
fungeren, op de manier zoals beschreven in hoofdstuk 7. Het is in dat geval alleen 
nodig de views te wijzigen die de aliassen definiëren als de naam van de brontabel 
wordt gewijzigd. 


8.4.2 Kolommen toevoegen en verwijderen 
Aan een tabel kun je eenvoudig nullkolommen toevoegen. We kunnen bijvoorbeeld 
de nullkolom DateCreated aan WORK toevoegen met het volgende ALTER-statement: 


ALTER TABLE WORK 
ADD DateCreated DateTime NULL; 


Zijn er andere kolomconstraints, zoals DEFAULT of UNIQUE, dan kun je deze op 
dezelfde manier in de kolomdefinitie opnemen als wanneer de kolomdefinitie deel 
uitmaakt van een CREATE TABLE-statement. Wees je er echter van bewust dat het 
toevoegen van een DEFAULT-constraint leidt tot een toepassing van de standaard- 
waarde op alle nieuwe rijen, maar dat bestaande rijen nullwaarden zullen hebben. 

Stel bijvoorbeeld dat je de standaardwaarde van DateCreated op 1/1/1goo wilt in- 
stellen om aan te geven dat er nog geen waarde is ingevoerd. Je gebruikt in dat geval 
het volgende ALTER-statement: 


ALTER TABLE WORK 
ADD DateCreated DateTime NULL DEFAULT '01/01/1900'; 


Deze opdracht zorgt ervoor dat DateCreated standaard wordt ingesteld op 1/1/19oo 
voor nieuwe rijen in WORK. Je moet de volgende query uitvoeren om bestaande 
rijen in te stellen: 


UPDATE WORK 
SET DateCreated ='01/01/1900' 
WHERE DateCreated IS NULL; 


8.4.3 NOT NULL-kolommen toevoegen 

Wil je een NOT NULL-kolom toevoegen, dan moet je de kolom eerst toevoegen als 
NULL. Je kunt alle rijen van de kolom dan een waarde geven met een soortgelijk 
UPDATE-statement als in de vorige paragraaf. De NULL voor DateCreated kun je 
na de update veranderen in NOT NULL met het volgende ALTER TABLE … ALTER 
COLUMN-statement: 


ALTER TABLE WORK 
ALTER COLUMN DateCreated DateTime NOT NULL: 


Deze opdracht zal echter ook weer falen als DateCreated ook maar één rij bevat die 
geen waarde heeft. 
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8.4.4 Kolommen verwijderen 


Niet-sleutelkolommen verwijderen is makkelijk. De kolom DateCreated kunnen we 
bijvoorbeeld als volgt uit WORK weghalen: 


ALTER TABLE WORK 
DROP COLUMN DateCreated; 


Moet een externe sleutelkolom worden verwijderd, dan moet je eerst de constraint 
weghalen die de externe sleutel definieert. Een dergelijke wijziging komt overeen 
met het verwijderen van een relatie en dat is een onderwerp dat we verderop in dit 
hoofdstuk bespreken. 

Moet de primaire sleutel worden verwijderd, dan moet eerst de primary key con- 
straint worden verwijderd. Daartoe moeten echter eerst alle externe sleutels worden 
verwijderd die de primaire sleutel gebruiken. De volgende stappen zijn dus nodig 
om de primaire sleutel van WORK te verwijderen en deze door de samenstelling 
(Title, Copy, ArtistID) te vervangen: 


* Verwijder de constraint WorkFK uit TRANS. 
e Verwijder de constraint WorkPK uit WORK. 
+ Maak de nieuwe constraint WorkPK met (Title, Copy, ArtistID). 


* Maak de nieuwe constraint WorkFK die verwijst naar (Title, Copy, ArtistID) in 
TRANS. 


* Verwijder de kolom WorkID. 


Het is belangrijk te verifiëren dat alle wijzigingen goed zijn uitgevoerd, voordat je 
WorkID verwijdert. Als deze eenmaal is verwijderd, kun je die op geen enkele ma- 


nier meer terughalen, behalve door het herstellen van de tabel WORK vanuit een 
back-up. 


8.4.5 Een datatype of de constraints van kolommen wijzigen 

Het datatype of de constraints van een kolom kun je wijzigen door de kolom te her- 
definiëren met de opdracht ALTER TABLE ALTER COLUMN. Als je echter een ko- 
lom van NULL in NOT NULL verandert, dan moeten alle rijen van de kolom een 
waarde bevatten, wil deze wijziging slagen. 

Sommige datatypen kunnen bovendien tot dataverlies leiden. Het wijzigen van 
Char(so) in Date zal er bijvoorbeeld toe leiden dat alle tekstvelden verloren gaan die 
niet met succes door het DBMS in een datumwaarde kunnen worden omgezet. In 
sommige gevallen kan het DBMS domweg weigeren de wijziging in de kolom uit te 
voeren. Het resultaat is afhankelijk van het gebruikte DBMS-product. 

Het omzetten van numerieke waarden in Char of Varchar zal normaliter slagen. 
Het omzetten van datum- of geldwaarden of andere meer specifieke datatypen in 
Char of Varchar zal meestal ook slagen. Het opnieuw omzetten van Char of Varchar 
in een datum-, geld- of numerieke waarde is echter riskant en misschien ook niet 
mogelijk. 
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Zou DateOf Birth in het schema van View Ridge gedefinieerd zijn als Char(4), dan 
zou het een riskante maar verstandige wijziging zijn ARTIST.DateOfBirth in Nume- 
ric(4,o) te veranderen. Dat zou verstandig zijn omdat alle waarden van deze kolom 
numeriek zijn. Denk aan de check-constraint die is gebruikt voor het definiëren van 
DateOfBirth (zie Figuur 7-11). De volgende code voert deze wijziging uit en vereen- 
voudigt de CHECK-constraint: 


ALTER TABLE ARTIST 
ALTER COLUMN DateOfBirth Numeric(4,0) NULL; 
ALTER TABLE ARTIST 
ADD CONSTRAINT NumericBirthYearCheck 
CHECK(Date0OfBirth > 1900 and DateOfBirth < 2100); 


De bestaande check-constraints voor DateOfBirth moeten nu verwijderd worden. 


8.4.6 Constraints toevoegen en verwijderen 
Constraints kunnen we toevoegen of verwijderen met de statements ALTER TABLE 
ADD CONSTRAINT en ALTER TABLE DROP CONSTRAINT. 


8.5 Kardinaliteiten en eigenschappen van relaties wijzigen 


Het wijzigen van kardinaliteiten is een veelvoorkomende taak bij het herontwerpen 
van databases. De minimumkardinaliteiten moeten soms gewijzigd worden van 
o in 1, of van 1 in o. De maximumkardinaliteit moet vaak gewijzigd worden van r:1 
in :N, of van r:N in N:M. Een andere mogelijkheid, die minder vaak voorkomt, is 
dat de maximumkardinaliteit moet worden verminderd van N:M in r:N, of van r:N 
in «1. Zoals je later zult zien, kan deze laatste wijziging alleen worden uitgevoerd 
met dataverlies. 


8.5.1 Minimumkardinaliteiten wijzigen 

Welke actie er moet worden ondernomen voor het wijzigen van de minimumkardi- 
naliteiten, hangt af van of de wijziging aan de kant van de parent of aan de kant van 
de child in de relatie moet worden uitgevoerd. 


8.5.2 De minimumkardinaliteiten wijzigen aan de kant van de parent 
Moet de wijziging aan de kant van de parent worden uitgevoerd — wat betekent dat 
de child al dan niet een parent moet hebben — dan is het wijzigen een kwestie van 
aangeven of er al dan niet nullwaarden zijn toegestaan voor de externe sleutel die 
de relatie representeert. Stel bijvoorbeeld dat de externe sleutel Afdelingsnummer 
voorkomt in de tabel WERKNEMER in de r:N-relatie van WERKNEMER naar AFDE- 
LING. Je kunt veranderen of een werknemer al dan niet een afdeling moet hebben 
door simpelweg de nulltoestand van Afdelingsnummer te wijzigen. 

Moet de minimumkardinaliteit worden veranderd van o in 1, dan moet de exter- 
ne sleutel, die null was, in NOT NULL worden veranderd. Een kolom kan alleen in 
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NOT NULL worden veranderd als alle rijen in de tabel een waarde hebben. Dat be- 
tekent in het geval van een externe sleutel dat elke record al moet zijn gerelateerd. Is 
dat niet het geval, dan moeten de records zodanig worden gewijzigd dat ze allemaal 
een relatie hebben, voordat de externe sleutel NOT NULL kan worden gemaakt. Elke 
werknemer uit het vorige voorbeeld moet aan een afdeling zijn gerelateerd, voordat 
Afdelingsnummer in NOT NULL kan worden veranderd. 

Het kan, afhankelijk van het gebruikte DBMS, nodig zijn de foreign key con- 
straint die de relatie definieert te verwijderen, voordat de externe sleutel kan worden 
gewijzigd. De foreign key constraint kan daarna opnieuw worden toegevoegd. De 
volgende SQL zal werken voor het voorgaande voorbeeld: 


ALTER TABLE WERKNEMER 
DROP CONSTRAINT AfdelingFK; 


ALTER TABLE WEKKNEMER 
ALTER COLUMN Afdelingsnummer Int NOT NULL: 


ALTER TABLE WERKNEMER 
ADD CONSTRAINT AfdelingFK FOREIGN KEY (Afdelingsnummer) 
REFERENCES AFDELING (Afdelingsnummer) 
ON UPDATE CASCADE; 


Het cascading-gedrag van UPDATE en DELETE moet worden opgegeven als de mi- 
nimumkardinaliteit wordt veranderd van o in 1. Updates moeten in dit voorbeeld 
cascading worden doorgegeven, maar verwijderingen niet (denk eraan dat het stan- 
daardgedrag NO ACTION is). 

De minimumkardinaliteit kan makkelijk van nul in r worden gewijzigd. Afde- 
lingsnummer kan simpelweg van NOT NULL in NULL worden gewijzigd. Je zult 
misschien, waar nodig, ook het gedrag voor het cascading doorgeven van updates en 
verwijderingen willen veranderen. 


8.5.3 De minimumkardinaliteiten wijzigen aan de kant van de child 
Zoals al in hoofdstuk 6 opgemerkt is de enige manier om een minimumkardinali- 
teit ongelijk aan o aan de kant van de child te handhaven, het schrijven van triggers 
(of van applicatiecode). Als je de minimumkardinaliteit wilt veranderen van o in 1 
moet je dus passende triggers schrijven. Gebruik Figuur 6-29 om het triggergedrag 
te ontwerpen en schrijf dan de triggers. De minimumkardinaliteit veranderen van 1 
in o doe je door simpelweg de triggers te verwijderen. 

Wil je in het voorbeeld met AFDELING en WERKNEMER vereisen dat elke AF- 
DELING een WERKNEMER heeft, dan moet je triggers schrijven voor INSERT van 
AFDELING en voor UPDATE en DELETE van WERKNEMER. De triggercode in 
AFDELING garandeert dat er een WERKNEMER aan de nieuwe AFDELING wordt 
toegekend. De triggercode in WERKNEMER garandeert dat de werknemer die naar 
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een nieuwe afdeling wordt verplaatst, of de werknemer die wordt verwijderd, niet de 
laatste werknemer is in de relatie met zijn parent. 

We gaan er daarbij van uit dat de voorwaarde voor de vereiste child wordt gehand- 
haafd door triggers. Als de constraint voor de vereiste child wordt gehandhaafd door 
applicaties, dan moeten die programma's ook gewijzigd worden. In dat geval moe- 
ten misschien tientallen programma's worden gewijzigd. Dat is een van de redenen 
waarom het beter is dergelijke constraints af te dwingen met triggers, in plaats van 
met applicatiecode. 


8.5.4 Maximumkardinaliteiten wijzigen 

De enige moeilijkheid in het vergroten van de kardinaliteiten van r:1 naar r:N of van 
EN naar N:M zit in het behouden van de bestaande relaties. Dat is mogelijk maar er 
is wat werk voor nodig zoals je zult zien. Als je kardinaliteiten vermindert, gaan er 
relaties verloren. In dat geval moet een beleid worden opgesteld om te bepalen welke 
relaties er verwijderd moeten worden. 


8.5.5 1:1 wijzigen in 1:N 

Figuur 8-6 laat een r:r-relatie zien tussen WERKNEMER en PARKEERVERGUN- 
NING. Je zag al in hoofdstuk 6 dat de externe sleutel in elk van de twee tabellen 
kan worden geplaatst bij een r:r-relatie. De externe sleutel moet echter als uniek 
zijn gedefinieerd, ongeacht waar deze is geplaatst, om de r:r-kardinaliteit te hand- 
haven. Welke actie ondernomen moet worden voor de tabellen in Figuur 8-6 is af- 
hankelijk van welke tabel de parent moet zijn in de r:N-relatie: WERKNEMER of 
PARKEERVERGUNNING. 


WERKNEMER PARKEERVERGUNNING 


\ Werknemernummer: NOT NULL SN vergunningnummer: NOT NULL 


Name: NOT NULL 
Telefoon: NOT NULL 
E-mail: NOT NULL 


DatumUitgegeven: NOT NULL 
Parkeerplaats: NOT NULL 
Werknemernummer: NOT NULL (FK) (AK1.1) 


Figuur 8-6 Voorbeeld van een 1:1-relatie 


Als WERKNEMER de parent is (een werknemer kan dan meer parkeervergunningen 
hebben), dan moet alleen de constraint worden verwijderd dat PARKEERVERGUN- 
NING.Werknemernummer uniek moet zijn. De relatie zal daarna r:N zijn. 

Als PARKEERVERGUNNING de parent is (als parkeervergunningen aan veel 
werknemers moeten worden toegekend, bijvoorbeeld voor carpooling), dan moeten 
de externe sleutel en de overeenkomstige waarden van PARKEERVERGUNNING 
naar WERKNEMER worden verplaatst. De volgende SQL doet dat: 


ALTER TABLE WERKNEMER 
ADD COLUMN Vergunningnummer Int NULL; 
UPDATE WERKNEMER 
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SET WERKNEMER. Vergunningnummer = 
(SELECT PV.Vergunningnummer 
FROM PARKEERVERGUNNING AS PV 
WHERE PV.Werknemernummer = WERKNEMER. Werknemernummer); 


De kolom Werknemernummer moet uit PARKEERVERGUNNING worden verwij- 
derd nadat de externe sleutel naar WERKNEMER is verplaatst. Maak daarna een 
nieuwe foreign key constraint om de referential integrity te definiëren. Het moet 
mogelijk zijn meer werknemers aan dezelfde parkeervergunning te koppelen. De 
nieuwe externe sleutel mag daarom geen UNIQUE-constraint hebben. 


8.5.6 1:N wijzigen in N:M 

Stel dat galerie View Ridge besluit dat het mogelijk moet zijn voor een gegeven trans- 
actie meer dan één koper op te slaan. Het kan zijn dat voor sommige kunstwerken 
geldt dat een klant en een bank mede-eigenaars zijn, of de galerie wil misschien 
beide namen opslaan als een kunstwerk door een echtpaar wordt gekocht. Deze wij- 


ziging zal, ongeacht waarom ze het willen doen, vereisen dat de r:N-relatie tussen 
CUSTOMER en TRANS wordt gewijzigd in een N:M-relatie. 


Een r:N-relatie kan verrassend eenvoudig worden gewijzigd.” Je hoeft alleen de nieu- 
we intersectietabel te maken, deze met gegevens te vullen en de oude externe sleu- 
telkolom te verwijderen. Figuur 8-7 laat het databaseontwerp van View Ridge zien, 
met een nieuwe intersectietabel voor de N:M-relatie. We moeten deze tabel maken 
en dan de waarden van TransactionID en Customer1D uit TRANS kopiëren voor alle 


rijen waarin CustomerlD niet null is. We maken eerst de intersectietabel met het 
volgende SQL-statement: 


CREATE TABLE CUSTOMER _TRANSACTION_INT( 

Customer1D Int NOT NULL, 

TransactionID Int NOT NULL, 

CONSTRAINT CustomerTransaction_PK 

PRIMARY KEY (CustomerID, TransactionID), 

CONSTRAINT Customer_Transaction_Int_TransactionFK 

FOREIGN KEY (TransactionID) REFERENCES TRANS (TransactionID), 
CONSTRAINT Customer_ Transaction _Int_Customer_FK 


FOREIGN KEY (CustomerID) REFERENCES CUSTOMER (CustomerID) 
); 


2 Dat wil zeggen: de gegevens kunnen eenvoudig gewijzigd worden. Het verwerken van de conse- 
quenties daarvan voor de views, triggers, opgeslagen procedures en applicatiecode zal moeilijker 
zijn. Deze moeten allemaal herschreven worden om met een join te werken via de nieuwe intersec: 
tietabel. Ook alle formulieren en rapporten moeten gewijzigd worden, zodat meer klanten opgege- 
ven kunnen worden voor een transactie — dat kan bijvoorbeeld betekenen dat tekstvakken in lijsten 
moeten worden veranderd. Dat is allemaal werk dat veel tijd in beslag neemt en duur is. 
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CUSTOMER_TRANSACTION_INT 


AN CustomerlD (FK) 
TransactionlD (FK) 


CUSTOMER 
EN CustomerlD AE 
ee TRANS WORK TS 
ee EN TransactionlD 
AANKOPEN / 
7 L AK1.1 
AreaCode VERKOCHT | _ DateAcquired Title men A St 
LocalNumber AAN AcquisitionPrice | , Description - E ame : 
Street DateSold Lie Medium Nationality 
City SalesPrice Copy DateOfBirth 
State AskingPrice ArtistID (FK) DateDeceased 
ZipPostalCode WorkID (FK) 
Country 
Eron (OMS) CUSTOMER ARTIST_INT 


NEE 


HEEFT INTERESSE IN 


PO 
BEWONDERD DOOR 


Figuur 8-7 Het databaseontwerp van View Ridge met een nieuwe N:M-relatie 


Merk op dat er geen cascading update is, omdat CustomerID een surrogaatsleutel is. 
Vanwege het bedrijfsbeleid nooit gegevens te verwijderen die met transacties te ma- 
ken hebben, is er geen cascading delete. 

De volgende taak is het invullen van de tabel met gegevens uit de tabel TRANS. 
We doen dat met het volgende SQL-statement: 


INSERT INTO CUSTOMER _TRANSACTION INT (CustomerID, 
TransactionID) 
SELECT CustomerID, TransactionID 
FROM TRANS 
WHERE CustomerID IS NOT NULL; 


Zijn al deze wijzigingen uitgevoerd, dan kan de kolom Customer D uit TRANS wor- 
den verwijderd. 


8.5.7 De kardinaliteiten verminderen (met dataverlies) 

Structurele wijzigingen voor het verminderen van de kardinaliteiten zijn eenvoudig 
uit te voeren. We verminderen een N:M-relatie tot 1:N door gewoon een nieuwe ex- 
terne sleutel te maken, die de child zal zijn in de relatie, en deze met gegevens uit 
de intersectietabel te vullen. We kunnen een r:N-relatie verminderen tot r:1 door 
de waarden van de externe sleutel in de r:N-relatie uniek te maken en dan een con- 
straint voor uniekheid te definiëren voor de externe sleutel. Het grootste probleem is 
in beide gevallen te besluiten welke gegevens er verloren moeten gaan. 


317 


DEEL 3 | OATABASES IMPLEMENTEREN 


Laten we eerst naar de vermindering van N:M naar r:N kijken. Stel bijvoorbeeld dat 
galerie View Ridge besluit voor elke klant maar één interesse in een kunstenaar bij te 
houden. De relatie zal r:N zijn van ARTIST naar CUSTOMER. We moeten dus een 
nieuwe externe sleutelkolom ArtistID aan CUSTOMER toevoegen en een foreign 
key constraint instellen naar ARTIST voor die klant. De volgende SQL doet dat: 


ALTER TABLE CUSTOMER 
ADD COLUMN ArtistID int null; 
ALTER TABLE CUSTOMER 
ADD CONSTRAINT ArtistInterestFK FOREIGN KEY (ArtistID) 
REFERENCES ARTIST (ArtistID); 


Updates hoeven niet cascading te worden uitgevoerd vanwege de surrogaatsleutel. 
Verwijderingen kunnen niet cascading worden doorgegeven, omdat de klant een gel- 
dige transactie kan hebben en hij niet verwijderd hoort te worden alleen omdat hij 
niet langer in een kunstenaar is geïnteresseerd. 

Maar welke van de mogelijk vele kunstenaars in wie de klant geïnteresseerd is, 
moet nu in de nieuwe relatie blijven bestaan? Het antwoord is afhankelijk van het 
bedrijfsbeleid van de galerie. We besluiten hier simpelweg de eerste te nemen: 


UPDATE CUSTOMER 


SET ArtistID = 
(SELECT Top 1 ArtistID 
FROM CUSTOMER ARTIST INT AS CAI 


WHERE CUSTOMER. CustomerID = CAI.CustomerID); 


De SQL-uitdrukking Top 1 wordt gebruikt om de eerste rij te leveren. 

Alle views, triggers, opgeslagen procedures en applicaties moeten worden gewijzigd 
om rekening te houden met de nieuwe r:N-relatie. Daarna kunnen de voor CUSTO- 
MER_ARTIST_INT gedefinieerde constraints worden verwijderd, waarna de tabel 
CUSTOMER_ARTIST_INT kan worden verwijderd. 

Willen we een r:N- in een r:1-relatie veranderen, dan moeten we alleen alle even- 
tuele dubbele waarden van de externe sleutel van de relatie verwijderen, en dan een 
constraint voor uniekheid aan de externe sleutel opleggen. Zie vraag s1 aan het einde 
van dit hoofdstuk. 


8.6 Relaties toevoegen en verwijderen 


Het toevoegen van nieuwe tabellen en relaties is niet moeilijk. Voeg die gewoon toe 
met CREATE TABLE-statements met FOREIGN KEY-constraints, zoals je dat al eer- 
der hebt gezien. Voeg een FOREIGN KEY-constraint toe met behulp van de bestaan- 
de tabel als deze een child-relatie heeft tot de nieuwe tabel. 

Zou er bijvoorbeeld een nieuwe tabel COUNTRY aan de View Ridge-database 
worden toegevoegd, met de primaire sleutel Name, en zou CUSTOMER.Country als 
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een externe sleutel naar de nieuwe tabel moeten worden gebruikt, dan zou er een 
nieuwe FOREIGN KEY-constraint worden gedefinieerd in CUSTOMER: 


ALTER TABLE CUSTOMER 
ADD CONSTRAINT CountryFK FOREIGN KEY (Country) 
REFERENCES COUNTRY (Name) 
ON UPDATE CASCADE; 


Het verwijderen van relaties en tabellen is simpelweg een zaak van het verwijderen 
van de foreign key constraints en dan van de tabellen. Voordat we dit doen, moeten 
we natuurlijk dependency-grafen maken en deze gebruiken om te bepalen op welke 
views, triggers, opgeslagen procedures en applicaties de verwijderingen betrekking 
hebben. 

Een andere, al in hoofdstuk 4 beschreven reden voor het toevoegen van nieuwe 
tabellen en relaties, of voor het comprimeren van bestaande tabellen in minder tabel- 
len, is normaliseren en denormaliseren. We merken hier alleen op dat het normali- 
seren en denormaliseren veelvoorkomende taken zijn tijdens het herontwerpen van 
databases. Verder gaan we in dit hoofdstuk niet op dat onderwerp in. 


8.7 Forward engineering 


Er bestaan allerlei datamodelleringproducten die wijzigingen voor je kunnen uitvoe- 
ren in databases. Je moet daartoe eerst een RE-datamodel van de database maken 
via reverse engineering, wijzigingen uitvoeren in het RE-datamodel en dan de func- 
tionaliteit voor forward engineering van het hulpprogramma voor datamodellering 
gebruiken. 

We gaan hier niet verder in op forward engineering, want deze verbergt de SQL 
die je moet leren. Hoe het proces van forward engineering precies werkt, verschilt 
bovendien van product tot product. 

Het goed uitvoeren van wijzigingen in het datamodel is zo belangrijk dat veel pro- 
fessionals het gebruik van een geautomatiseerd proces voor het herontwerpen van 
databases met de nodige scepsis bekijken. De resultaten moeten in elk geval grondig 
worden getest, voordat forward engineering wordt toegepast op operationele gege- 
vens. Sommige producten laten je zien welke SQL ze zullen uitvoeren, zodat je deze 
kunt controleren voordat je de database wijzigt. 

Bij het herontwerpen van databases is het misschien geen goed idee gebruik te 
maken van automatisering. Dat hangt sterk af van de aard van de wijzigingen die 
moeten worden uitgevoerd, en van de kwaliteit van de functies voor forward enginee- 
ring van het datamodelleringproduct. Met de kennis die je in dit hoofdstuk opdeed, 
ben je in staat de meeste wijzigingen voor het herontwerpen uit te voeren met zelf. 
geschreven SQL. Er is ook niets mis met deze werkwijze! 
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Samenvatting 


De derde manier waarop databases kunnen ontstaan, is door ze te herontwerpen. 
Herontwerpen is nodig om vergissingen die tijdens het ontwerpen van de originele 
database zijn gemaakt te verhelpen. Het is ook van belang als een database aangepast 
moet worden aan veranderende systeemeisen. Dergelijke wijzigingen zijn onont- 
koombaar, want informatiesystemen en organisaties beïnvloeden elkaar niet alleen, 
ze creëren elkaar. Nieuwe informatiesystemen leiden daarom tot wijzigingen in de 
systeemeisen. 

Gecorreleerde subquery's en EXISTS/NOT EXISTS zijn belangrijke SQL-state- 
ments. Ze zijn te gebruiken voor het beantwoorden van geavanceerde query’s en zijn 
nuttig tijdens het herontwerpen van databases, om te bepalen of opgegeven gege- 
vensomstandigheden bestaan. We kunnen ze bijvoorbeeld gebruiken om te bepalen 
of mogelijke functionele afhankelijkheden voorkomen in de gegevens. 

Een gecorreleerde subquery lijkt bedrieglijk veel op een gewone subquery. Bij 
een gewone subquery worden eerst de resultaten van de onderste query bepaald, die 
dan kunnen worden gebruikt voor het evalueren van de daarboven staande query's. 
In een gecorreleerde subquery is de verwerking genest — dat wil zeggen: een rij van 
een van de bovenste query’s wordt vergeleken met rijen in een query op een lager ni- 
veau. Het belangrijkste verschil is dat de onderste SELECT-statements van een gecor- 
releerde subquery gebruikmaken van kolommen uit daarboven staande statements. 

EXISTS en NOT EXISTS zijn gespecialiseerde vormen van gecorreleerde subque- 
ry's waarmee de query op het hoogste niveau resultaten levert, die afhankelijk zijn 
van het al dan niet bestaan van rijen in query’s op een lager niveau. Een EXISTS-con- 
straint is waar als een willekeurige rij in de subquery aan de opgegeven constraints 
voldoet. Een NOT EXISTS-constraint is alleen waar als alle rijen in de subquery niet 
aan de opgegeven constraints voldoen. NOT EXISTS is nuttig voor query’s die con- 
straints omvatten die waar moeten zijn voor alle rijen, zoals ‘een klant die alle pro- 
ducten heeft aangeschaft’. Het dubbele gebruik van NOT EXISTS (paragraaf 8.2.9) 
is een beroemd SQL-patroon dat wordt gebruikt voor het testen van de kennis van 
SQL. 

Een bestaande database moet nauwkeurig worden onderzocht voordat je deze 
opnieuw ontwerpt. Dit is om te vermijden dat de database onbruikbaar wordt door- 
dat een wijziging in de database maar voor een deel wordt verwerkt. De regel is dat 
je tweemaal moet meten voordat je eenmaal snijdt. Reverse engineering wordt ge- 
bruikt voor het maken van een datamodel van de bestaande database. Dat wordt ge- 
daan om de structuur van de database beter te begrijpen voordat een wijziging wordt 
doorgevoerd. Het geproduceerde datamodel, dat we een reverse engineered (RE)-da- 
tamodel noemen, is eigenlijk geen echt datamodel — het is een apart ding. De meeste 
hulpprogramma's voor datamodellering kunnen reverse engineering uitvoeren. Er 
ontbreken vrijwel altijd gegevens in het RE-datamodel — dergelijke modellen moeten 
nauwgezet worden gecontroleerd. 

Alle elementen van een database zijn aan elkaar gerelateerd. Dependency-gra- 
fen worden gebruikt voor het weergeven van de onderlinge afhankelijkheid. Een 
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wijziging in een tabel kan bijvoorbeeld invloed hebben op relaties, views, indexen, 
triggers, opgeslagen procedures en applicaties. Deze invloed moet bekend zijn en je 
moet er rekening mee houden voordat de database wordt gewijzigd. 

Je moet een volledige back-up maken van de operationele database voordat je 
er wijzigingen voor het herontwerpen in aanbrengt. Dergelijke wijzigingen moeten 
bovendien grondig worden getest. Dat moet eerst worden gedaan met kleine test- 
databases en later met grotere testdatabases, die misschien zelfs duplicaten van de 
operationele database zijn. De wijzigingen voor het herontwerpen worden pas uitge- 
voerd nadat er uitgebreide tests zijn uitgevoerd. 

Wijzigingen voor het herontwerpen van databases kunnen we in verschillende 
typen groeperen. Een van deze typen heeft te maken met het wijzigen van namen 
en kolommen van tabellen. Het wijzigen van een tabelnaam heeft een verrassend 
groot aantal mogelijke consequenties. Je moet een dependency-graaf gebruiken om 
deze consequenties te begrijpen voordat de wijziging wordt doorgevoerd. Niet-sleu- 
telkolommen kunnen probleemloos worden toegevoegd en verwijderd. Het toevoe- 
gen van een NOT NULL-kolom gebeurt in drie stappen: voeg de kolom eerst toe als 
NULL, voeg dan gegevens toe aan elke rij en wijzig dan de kolomconstraint in NOT 
NULL. Wil je een kolom verwijderen die als een externe sleutel wordt gebruikt, dan 
moet je eerst de foreign key constraint verwijderen. 

Datatypen en constraints van kolommen kunnen worden gewijzigd met het 
statement ALTER TABLE … ALTER COLUMN. Een meer specifiek datatype zoals 
de datum kan meestal probleemloos in een minder specifiek type worden veran- 
derd, zoals Char of Varchar. Het wijzigen van een datatype van Char of Varchar in 
een meer specifiek type kan een probleem opleveren. Er zullen in sommige gevallen 
gegevens verloren gaan, of het DBMS kan weigeren de wijziging uit te voeren. Con- 
straints kunnen worden toegevoegd of verwijderd met het statement ALTER TABLE 
… ADD/DROP CONSTRAINT. Dit statement kan makkelijker worden gebruikt als 
de ontwikkelaars alle constraints een eigen naam hebben gegeven. 

De maximumkardinaliteit kan makkelijk van r:1 in r:N worden veranderd als de 
externe sleutel in de goede tabel staat. Je kunt in dat geval simpelweg de constraint 
voor uniekheid verwijderen uit de externe sleutelkolom. Staat de externe sleutel in 
de verkeerde tabel voor deze wijziging, dan moet je de externe sleutel eerst naar de 
andere tabel verplaatsen, zonder een constraint voor uniekheid aan die tabel op te 
leggen. 

Het veranderen van een r:N- in een N:M-relatie vereist dat er een nieuwe inter- 
sectietabel wordt gemaakt en dat de sleutel- en externe sleutelwaarden naar de inter- 
sectietabel worden verplaatst. Dat aspect van de wijziging is relatief eenvoudig. Alle 
views, triggers, opgeslagen procedures, applicaties, formulieren en rapporten moe- 
ten gewijzigd worden om gebruik te maken van de nieuwe intersectietabel — dat is 
een stuk ingewikkelder. 

Kardinaliteiten kunnen makkelijk worden verminderd, maar dergelijke wijzigin- 
gen kunnen leiden tot het verlies van gegevens. Voordat dergelijke verminderingen 
worden uitgevoerd, moet eerst een beleid worden opgezet om te besluiten welke ge- 
gevens behouden moeten blijven. Het veranderen van N:M in r:N omvat het maken 
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van een externe sleutel in de parent-tabel en het verplaatsen van een waarde van de 
intersectietabel naar die externe sleutel. Voor het veranderen van r:N in r:r moeten 
eerst duplicaten in de externe sleutel worden verwijderd, waarna een constraint voor 
uniekheid aan die sleutel moet worden opgelegd. Relaties kunnen worden toege- 
voegd en verwijderd door nieuwe foreign key constraints te definiëren, of door be- 
staande foreign key constraints te laten vallen. 

De meeste tools voor datamodellering zijn in staat forward engineering uit te 
voeren. Dat is het proces van het toepassen van wijzigingen in het datamodel op een 
bestaande database. Wordt forward engineering gebruikt, dan moeten de resultaten 
grondig worden gecontroleerd voordat ze op een operationele database worden toe- 
gepast. Sommige hulpprogramma's laten de SQL zien die ze uitvoeren tijdens het 
proces van de forward engineering. Deze SQL moet in dat geval precies worden ge- 
controleerd. SQL-statements voor het herontwerpen van databases kunnen we al met 
al evengoed met de hand schrijven, in plaats van forward engineering te gebruiken. 


Belangrijke termen 


dependency-graaf NOT EXISTS 


EXISTS reversed engineered(RE)-datamodel 
gecorreleerde subquery’s 


Oefeningen 


Leg (nog eens) uit op welke drie manieren databases kunnen ontstaan. 

2. Leg uit waarom het herontwerpen van databases nodig is. 

3. Leg de volgende verklaring uit in eigen woorden: ‘Informatiesystemen en orga- 
nisaties creëren elkaar.’ Wat is het verband daarvan met het herontwerpen van 
databases? 

4. Stel dat een tabel twee niet-sleutelkolommen bevat: AdviseurNaam en Advi- 

seurTelefoon. Stel verder dat je vermoedt dat AdviseurTelefoon — Adviseur- 

Naam. Leg uit hoe je te werk gaat om te bepalen of de gegevens deze aanname 

ondersteunen. 

Schrijf zelf een subquery die geen gecorreleerde subquery is. 

Leg uit waarom de verwerking van gecorreleerde subquery’s genest is, terwijl de 

verwerking van gewone subquery’s dat niet is. 

7. Schrijf zelf een gecorreleerde subquery. 

8. Leg uit waarin de query in je antwoord op vraag 5 verschilt van de query in je 
antwoord op vraag 7. 

g. Leg uit wat er aan de gecorreleerde subquery in paragraaf 8.2.5 mankeert. 

io. Schrijf een gecorreleerde subquery die bepaalt of de gegevens de veronderstel- 
ling uit vraag 4 ondersteunen. 

ir. Leg de betekenis uit van het sleutelwoord EXISTS. 

12. Beantwoord vraag 1o, maar gebruik EXISTS. 


CN 
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27. 


28. 


29. 


30. 


31 


32. 


33- 


34. 


35- 


36. 
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Leg uit wat het verschil is tussen het gebruik van elke en alle tussen EXISTS en 
NOT EXISTS. 

Leg uit hoe de query in paragraaf 8.2.9 wordt verwerkt. 

Schrijf een query die de namen zal weergeven van alle klanten die geïnteres- 
seerd zijn in alle kunstenaars. 

Leg uit hoe de query in je antwoord op vraag 15 werkt. 

Waarom is het belangrijk de database te analyseren voordat taken voor het her- 
ontwerpen van de database worden geïmplementeerd? Wat kan er gebeuren als 
je dit niet doet? 

Leg het proces van reverse engineering uit. 

Waarom is het belangrijk de resultaten van reverse engineering nauwgezet te 
evalueren? 


„ Wat is een dependency-graaf? Wat is het doel daarvan? 


Leg de afhankelijkheden voor WORK uit in de graaf in Figuur 8-5. 


„ Welke bronnen worden er gebruikt voor het maken van een dependency-graaf? 


Licht twee soorten testdatabases toe die moeten worden gebruikt tijdens het tes- 
ten van wijzigingen voor het herontwerpen van een database. 

Leg uit welke problemen er kunnen optreden als de naam van een tabel wordt 
veranderd. 

Beschrijf het proces van het wijzigen van een tabelnaam. 


. Beschrijf welke taken er moeten worden uitgevoerd om de naam van de tabel 


WORK uit Figuur 8-5 in WORK VERSIONza te veranderen. 

Leg uit hoe views het proces van het wijzigen van een tabelnaam kunnen 
vereenvoudigen. 

Onder welke omstandigheden is het volgende SQL-statement geldig? 


INSERT INTO TALSSCAG RB) 
SELECT «(CDI AEROMATZS 


Geef een SQL-statement dat een integerkolom Cr aan tabel Ta toevoegt. Neem 
aan dat Cr NULL is. 

Breid je antwoord op vraag 29 uit om Cr toe te voegen als Cr NOT NULL moet 
zijn. 

Geef een SQL-statement voor het verwijderen van kolom Cr uit tabel T2. 
Beschrijf het proces voor het verwijderen van de primaire sleutel Cr en voor het 
maken van de nieuwe primaire sleutel Ca. 

Welke wijzigingen in het datatype zijn het minst riskant? 

Welke wijzigingen in het datatype zijn het meest riskant? 

Geef een SQL-statement voor het wijzigen van een kolom Cr in Char(to) NOT 
NULL. Aan welke constraints moeten de gegevens voldoen om deze wijziging te 
laten slagen? 

Leg uit hoe je de minimumkardinaliteit verandert als een child die een parent 
moest hebben nu geen parent meer hoeft te hebben. 
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37: 


38. 
39. 
40. 
41. 


42. 


43. 


44. 


45: 


46. 


47. 


48. 


49. 


50. 


Leg uit hoe je de minimumkardinaliteit verandert als een child die geen parent 
hoefde te hebben nu wel een parent moet hebben. Aan welke constraint moeten 
de gegevens voldoen om deze wijziging te laten slagen? 

Leg uit hoe je de minimumkardinaliteit verandert als een parent die een child 
moest hebben nu geen child meer hoeft te hebben. 

Leg uit hoe je de minimumkardinaliteit verandert als een parent die geen child 
hoefde te hebben nu wel een child moet hebben. 
Beschrijf hoe je de maximumkardinaliteit verandert van r:1 in r:N. Neem aan 
dat de externe sleutel aan de kant van de nieuwe child staat in de r:N-relatie. 
Beschrijf hoe je de maximumkardinaliteit verandert van r:r in r:N. Neem aan 
dat de externe sleutel aan de kant van de nieuwe parent staat in de r:N-relatie. 
Neem aan dat de tabellen Tr en T2 een r:r-relatie hebben. Neem aan dat T2 de 
externe sleutel bevat. Laat zien welke SQL-statements nodig zijn voor het ver- 
plaatsen van de externe sleutel naar Tr. Maak zelf aannames over de namen van 
sleutels en externe sleutels. 

Leg uit hoe je een 1:N-relatie omzet in een N:M-relatie. 

Stel dat de tabellen Tr en T2 een r:N-relatie hebben. Laat zien welke SQL-state- 
ments nodig zijn voor het vullen van een intersectietabel Tr_T2_INT. Maak zelf 
aannames over de namen van sleutels en externe sleutels. 

Leg uit hoe het verminderen van de maximumkardinaliteiten tot dataverlies 
leidt. 

Gebruik de tabellen uit je antwoord op vraag 44 en laat zien welke SQL-state- 
ments nodig zijn voor het terugveranderen van de relatie in r:N. Neem aan dat 
de eerste rij in de kwalificerende rijen van de intersectietabel de externe sleu- 
tel moet leveren. Gebruik de sleutels en externe sleutels van je antwoord op 
vraag 44. 

Gebruik de resultaten van je antwoord op vraag 46 en leg uit wat er gedaan moet 
worden om deze relatie om te zetten in 1:1. Gebruik de sleutels en externe sleu- 
tels van je antwoord op vraag 46. 


Leg in algemene termen uit wat er gedaan moet worden om een nieuwe relatie 
toe te voegen. 

Stel dat de tabellen Tr en T2 een r:N-relatie hebben, met Ta als de child. Laat 
zien welke SQL-statements er nodig zijn voor het verwijderen van de tabel T2. 
Maak zelf aannames over de namen van sleutels en externe sleutels. 

Wat zijn de problemen en gevaren van forward engineering? 


Projectvragen 


SL 
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Stel dat de tabel WERKNEMER een r:N-relatie heeft met de tabel TELEFOON- 
NUMMER. Stel verder dat WERKNEMER de sleutel WerknemerID heeft en dat 
TELEFOONNUMMER de volgende kolommen heeft: TLnummer (een surro- 
gate key), Netnummer, Abonneenummer en WerknemeriD (een externe sleu- 
tel naar WERKNEMER). Wijzig dit ontwerp zodat WERKNEMER een r:r-relatie 
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heeft met TELEFOONNUMMER. Bewaar alleen het eerste telefoonnummer 
van werknemers die meer telefoonnummers hebben. 

Neem aan dat de tabel WORK van View Ridge is vervangen door de in dit hoofd- 
stuk beschreven tabel ARTIST WORK. Schrijf SQL-statements voor het ver- 
plaatsen van de externe sleutel voor de relatie WORK/CUSTOMER naar de 
relatie ARTIST WORK/CUSTOMER. Neem aan dat je de externe sleutelkolom 
ARTIST_WORK moet toevoegen, dat je de relatie moet definiëren en dat je de 
juiste waarden moet verplaatsen. Verwijder als dat allemaal is gedaan de externe 
sleutel CUSTOMER uit WORK. 

Kijk eens naar de volgende tabel: 


TAAK (WerknemerID, Naam, Telefoon, Kantoornummer, Projectnaam, 
Sponsor, WerkDatum, UrenGewerkt) 


met de volgende mogelijke functionele afhankelijkheden: 


WerknemerID — (Naam, Telefoon, Kantoornummer) 
Projectnaam — Sponsor 


a. Schrijf SQL-statements voor het weergeven van de waarden van alle rijen 
die deze functionele afhankelijkheden schenden. 

b. Kunnen we aannemen dat deze functionele afhankelijkheden geldig zijn 
als er geen gegevens zijn die ze schenden? Waarom, of waarom niet? 

c._ Neem aan dat deze functionele afhankelijkheden waar zijn en dat de ge- 
gevens waar nodig gecorrigeerd zijn om deze afhankelijkheden te weer- 
spiegelen. Schrijf alle SQL-statements die nodig zijn om deze tabel te 
herontwerpen in de domein/sleutel-normaalvorm. Neem aan dat de tabel 
gegevenswaarden bevat die op een passende manier naar het nieuwe ont- 
werp moeten worden omgezet. 


Marcia’s Chemische Reiniging 


Neem aan dat Marcia een database heeft gemaakt met de volgende tabellen: 


CUSTOMER (CustomerID, FirstName, LastName, Phone, E-mail) 
INVOICE (InvoiceNumber, CustomerID, Dateln, Date0ut, 
Subtotal, Tax, TotalAmount) 
INVOICE ITEM (InvoiceNumber, ItemNumber, Service, Quantity, 
UnitPrice, ExtendedPrice) 
SERVICE (Service, Description, UnitPrice) 


Neem aan dat alle relaties zijn gedefinieerd zoals aangegeven door de externe 
sleutels in deze lijst met tabellen. 
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Maak een dependency-graaf die de afhankelijkheden tussen deze tabellen weer- 
geeft. Leg uit hoe je deze graaf moet uitbreiden voor views en andere database- 
constructies, zoals triggers en opgeslagen procedures. 

Gebruik je dependency-graaf en beschrijf welke taken er uitgevoerd moeten 
worden om de naam van de tabel INVOICE in CUST_INVOICE te veranderen. 
Schrijf alle SQL-statements die nodig zijn voor het uitvoeren van de naamsver- 
andering uit B. 

Stel dat Marcia besluit meer klanten per order toe te staan (bijvoorbeeld voor de 
echtgenoten van klanten). Wijzig het ontwerp van deze tabellen overeenkomstig. 
Schrijf de SQL-statements die nodig zijn voor het herontwerpen van de data- 
base, zoals beschreven in je antwoord op vraag D. 

Stel dat Marcia overweegt de primaire sleutel van CUSTOMER te veranderen 
in (FirstName, LastName). Schrijf gecorreleerde subquery’s voor het weergeven 
van alle eventuele gegevens die aangeven dat deze wijziging niet gerechtvaar- 
digd is. 

Stel dat (FirstName, LastName) tot de primaire sleutel van CUSTOMER kan 
worden gemaakt. Voer de wijzigingen in het tabelontwerp met deze nieuwe pri- 
maire sleutel in. 


Schrijf alle SQL-statements die nodig zijn voor het implementeren van de in 
vraag G beschreven wijzigingen. 


Importbedrijf Morgan 


Neem aan dat Morgan een database heeft gemaakt met de volgende tabellen: 


STORE (StoreID, StoreName, City, Country, Phone, Fax, E-mail, 
Contact) 
PURCHASE (PurchaselD, StorelD, Date, Description, Category, 
PriceUSD) 


SHIPMENT (ShipmentID, ShipDate, ShipperID, 
ShipperInvoiceNumber, Origin, Destination) 

SHIPMENT ITEM (ShipmentID, PurchaselD, InsuredValue) 
SHIPPER (ShipperID, Phone, Fax, E-mail, Contact) 


Neem aan dat alle relaties zijn gedefinieerd zoals aangegeven door de externe sleu- 
tels in deze lijst met tabellen. 


À. 
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Maak een dependency-graaf die de afhankelijkheden tussen deze tabellen weer- 
geeft. Leg uit hoe je deze graaf moet uitbreiden voor views en andere database- 
constructies, zoals opgeslagen procedures. 

Gebruik je dependency-graaf en beschrijf welke taken er uitgevoerd moeten 
worden om de naam van de tabel SHIPMENT in MORGAN_ SHIPMENT te 
veranderen. 

Schrijf alle SQL-statements die nodig zijn voor het uitvoeren van de naamsver- 
andering uit B. 
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Stel dat Morgan besluit sommige aankopen over meer ladingen te verdelen. 
Wijzig het ontwerp overeenkomstig dat nieuwe feit. Je zult aannames moeten 
maken over hoe aankopen worden verdeeld en hoe ze aan ladingen worden toe- 
gekend. Noem je aannames. 

Schrijf de SQL-statements die nodig zijn voor het implementeren van je aanbe- 
velingen voor het herontwerpen in je antwoord op vraag D. 

Stel dat Morgan overweegt de primaire sleutel van PURCHASE te veranderen 
in (StorelD, Date). Schrijf gecorreleerde subquery’s voor het weergeven van alle 
eventuele gegevens die aangeven dat deze wijziging niet gerechtvaardigd is. 
Stel dat (Storel D, Date) tot de primaire sleutel van PURCHASE kan worden ge- 
maakt. Voer de wijzigingen in het tabelontwerp uit die nodig zijn om Telefoon 
tot de primaire sleutel te maken. 

Schrijf alle SQL-statements die nodig zijn voor het implementeren van de in 
vraag G beschreven wijzigingen. 
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Multi-user- 
databaseverwerking 


De hoofdstukken in deel 4 beschrijven belangrijke onderwerpen en problemen van 
multi-user-databases, evenals door DBMS-producten geboden voorzieningen en 
functies voor het oplossen van deze problemen. We beginnen in hoofdstuk 9 met 
een beschrijving van het databasebeheer en de belangrijkste taken en technieken 
voor het beheren van multi-user-databases. Het volgende hoofdstuk illustreert het 
implementeren van deze concepten met SQL Server. 


Hoofdstuk 9 
Multi-user-databases beheren 


Multi-user-databases zijn van grote waarde voor organisaties die ze creëren en ge- 
bruiken, maar zorgen tegelijkertijd voor problemen. Ten eerste zijn het ontwerp en 
de ontwikkeling van multi-user-databases vrij ingewikkeld, omdat ze vele userviews 
ondersteunen die elkaar overlappen. Bovendien veranderen de specificaties in de loop 
van de tijd, zoals al in het vorige hoofdstuk werd besproken, wat tot gevolg heeft dat 
wijzigingen in de databasestructuur nodig zijn. Dergelijke structurele wijzigingen moe- 
ten zorgvuldig worden gepland en gecontroleerd, zodat een wijziging voor de ene 
groep geen problemen veroorzaakt bij een andere. Als verscheidene gebruikers tege- 
lijkertijd een database raadplegen, zijn er ook speciale besturingselementen nodig om 
te voorkomen dat de handelingen van de ene gebruiker de resultaten van een andere 
gebruiker nadelig beïnvloeden. We zullen later zien dat dit een belangrijk en ingewik- 
keld onderwerp is. 

In grote organisaties moeten verschillende verwerkingsrechten en -verantwoorde- 
lijkheden worden gedefinieerd en opgelegd. Wat gebeurt er bijvoorbeeld als een be- 
paalde werknemer het bedrijf verlaat? Wanneer kunnen zijn of haar records worden 
verwijderd? Voor de salarisadministratie kunnen deze records worden verwijderd zo- 
dra de laatste betaling is verwerkt. Voor het kwartaaloverzicht mag dat pas gebeuren 
nadat een bepaald kwartaal is verstreken, de accountant bewaart de gegevens graag 
tot na het eind van het kalenderjaar, enzovoort. je ziet dat niet door één afdeling kan 
worden besloten wanneer gegevens kunnen worden verwijderd. Dezelfde argumen- 
ten gelden voor het invoegen en wijzigen van gegevens. Om deze en andere redenen 
moeten beveiligingssystemen worden ontwikkeld, die alleen bevoegde personen in 
staat stellen bepaalde handelingen op bepaalde tijdstippen te verrichten. 


DEEL 4 | MULTI-USER-OATABASEVERWERKING 


Het DBMS zelf zal ten slotte moeten worden aangepast om de prestaties te ver- 
beteren, om ruimte te maken voor nieuwe functies en mogelijkheden, en om in 
overeenstemming te worden gebracht met wijzigingen die in het onderliggende be- 
sturingssysteem zijn aangebracht. 

Om ervoor te zorgen dat al deze problemen aandacht krijgen en dat ze worden 
opgelost, hebben de meeste organisaties een databasebeheerteam. We beginnen met 
een beschrijving van de taken in een dergelijk team. In de rest van dit hoofdstuk be- 
schrijven we de combinatie van software en handmatige methoden en procedures 
die worden gehanteerd om die taken uit te voeren. In het volgende hoofdstuk behan- 
delen we functies en mogelijkheden van SQL Server waarmee deze problemen zijn 
op te lossen. 


9.1 Databasebeheer 


In de praktijk gebruiken we zowel de term databeheer als databasebeheer. Soms 
worden de twee termen als synoniemen beschouwd, maar er kunnen ook verschil- 
lende betekenissen aan worden gegeven. De term databeheer wordt meestal gebruikt 
voor een functie die van toepassing is op een hele organisatie. Dit is een op het ma- 
nagement gerichte functie die bedrijfsomvattende dataprivacy en datasecurity be- 
treft. De term databasebeheer heeft betrekking op een functie die specifiek is voor een 
bepaalde database, inclusief de applicaties die deze database verwerken. Dit hoofd- 
stuk gaat over databasebeheer. 

Databases variëren enorm in grootte en bereik, van een individuele of persoon- 
lijke database tot een grote organisatiedatabase zoals voor de reservering van passa- 
giersstoelen op vluchten. Al deze databases hebben behoefte aan een databasebeheer, 
maar de uit te voeren taken variëren behoorlijk in complexiteit. Bij een persoonlijke 
database kunnen gebruikers bijvoorbeeld aan de hand van eenvoudige procedures 
reservekopieën van hun gegevens opslaan en is weinig documentatie vereist. In een 
dergelijke situatie voert de gebruiker van de database ook de functies voor het da- 
tabasebeheer uit, hoewel hij of zij zich daar waarschijnlijk niet eens van bewust is. 

Voor multi-user-databaseapplicaties wordt databasebeheer belangrijker en tege- 
lijkertijd ingewikkelder. Daarom is deze vorm van beheer vaak geformaliseerd. Bij 
bepaalde applicaties kan het beheer door een of twee parttime medewerkers worden 
uitgevoerd, maar voor internet- en intranetdatabases zijn de taken meestal zo uitge- 
breid en tijdrovend dat zelfs een fulltime medewerker vaak niet genoeg is. De onder- 
steuning van een database met tientallen of honderden gebruikers neemt veel tijd in 
beslag en vraagt aardig wat technische kennis en diplomatieke vaardigheden, zodat 
de werkzaamheden in dat geval meestal door een databasebeheerteam worden ver- 
richt. De manager van het team is de databasebeheerder — als we het in het vervolg 
hebben over een DBA (de afkorting van de Engelse term Database Administrator) 
bedoelen we het team of de manager van dat team. 

Het is de taak van de DBA de database te ontwikkelen en te onderhouden. 
Vaak betekent dit zoeken naar compromissen tussen de tegenstrijdige doelen van 
het beschermen van de database en het geven van zo veel mogelijk vrijheid en 
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gebruiksgemak aan de gebruiker. De DBA is dus verantwoordelijk voor de ontwikke- 
ling, de werking en het onderhoud van de database en bijbehorende applicaties. In 
Figuur 9-1 zie je een overzicht van de specifieke taken — in de volgende paragrafen 
gaan we op elke taak afzonderlijk in. 


e Beheer van de databasestructuur 


* Besturen van gelijktijdige dataverwerking 


* Beheer van verwerkingsrechten en -plichten 
e Ontwikkelen van databasebeveiliging 

* Voorzien in database recovery 

e Beheer van het DBMS 


* Onderhoud van de data-repository 


Figuur 9-1 Overzicht van de taken van het databasebeheer 


9.2 Beheer van de databasestructuur 


Het beheer van de databasestructuur omvat deelname aan het ontwerp en de imple- 
mentatie van de oorspronkelijke database, en de controle en het beheer van wijzigin- 
gen die erin worden aangebracht. De DBA is in het ideale geval in een vroegtijdig 
stadium betrokken bij de ontwikkeling van de database en bijbehorende applicaties, 
helpt bij het opstellen van de specificaties, kijkt met anderen naar eventuele alterna- 
tieven, zoals het gebruikte DBMS, en helpt bij de opzet van de databasestructuur. Bij 
grote organisatieapplicaties is de DBA meestal een manager die de leiding heeft over 
een groep specialisten op het gebied van databaseontwerpen. 

Het creëren van een database bestaat uit verschillende taken. Eerst wordt de da- 
tabase gecreëerd en wordt schijfruimte gereserveerd voor de databasegegevens en 
logbestanden. Vervolgens worden tabellen gegenereerd, indexen gecreëerd en opge- 
slagen procedures en triggers geschreven. In de volgende twee hoofdstukken geven 
we hier voorbeelden van. Als de databasestructuren eenmaal zijn opgesteld, wordt de 
database met gegevens gevuld. 


9.2.1 Configuratiebeheer 

Nadat een database en de bijbehorende applicaties zijn geïmplementeerd, treden er 
ongetwijfeld wijzigingen op in de specificaties, zoals we dat in hoofdstuk 8 beschre- 
ven. Zulke veranderingen kunnen voortvloeien uit nieuwe wensen, veranderingen 
in de zakelijke omgeving, veranderingen in het beleid en veranderingen in bedrijfs- 
processen die ontstaan terwijl het systeem wordt gebruikt. Als wijzigingen in de 
specificaties wijzigingen in de databasestructuur tot gevolg hebben, moeten we goed 


oppassen omdat dergelijke wijzigingen zelden op slechts één applicatie betrekking 
hebben. 
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Een effectief databasebeheer bestaat daarom uit procedures aan de hand waarvan ge- 
bruikers wijzigingen in de database kunnen voorstellen. Alle betrokkenen kunnen 
de voorgestelde veranderingen bespreken, waarna een besluit kan worden genomen 
over het al dan niet invoeren van de wijzigingen. Vanwege de grootte en complexiteit 
van een database en bijbehorende applicaties, hebben wijzigingen soms onverwach- 
te gevolgen. De DBA moet dus klaarstaan om de database te repareren en informatie 
kunnen achterhalen over de oorzaak van het probleem. De database is het kwets- 
baarst na een aangebrachte verandering in de structuur ervan. 


9.2.2 Documentatie 
Ook een belangrijke verantwoordelijkheid van de DBA bij het beheer van een data- 
basestructuur is goede documentatie. Het is enorm belangrijk te weten welke wij- 
zigingen zijn aangebracht en hoe en wanneer dit is gedaan. Een wijziging in de 
databasestructuur kan zorgen voor een fout die pas na zes maanden aan het licht 
komt — zonder goede documentatie van de wijziging is een diagnose van het pro- 
bleem erg lastig, zo niet onmogelijk. Daarom is het ook van belang een verslag bij te 
houden van de gehanteerde testprocedures en uitgevoerde testen. Als hiervoor ge- 
standaardiseerde procedures, formulieren en methoden worden gehanteerd, hoeft 
het vastleggen van de testresultaten niet veel tijd te kosten. 

Het bijhouden van documentatie is misschien meestal geen leuk werk, maar een 
goede documentatie is het verschil tussen een snelle probleemoplossing en een ver- 
warrende poel van activiteiten. Er zijn tegenwoordig verscheidene producten op de 
markt die het vastleggen van documentatie aanzienlijk vereenvoudigen. Zo kunnen 
veel CASE-tools worden gebruikt om logische databaseontwerpen te documenteren. 
Versiebeheertools kunnen worden gebruikt om wijzigingen bij te houden. De data- 
dictionary’s produceren rapporten en overzichten waarmee de gegevensstructuren 
van een database kunnen worden gelezen en geïnterpreteerd. 

Een andere reden om wijzigingen in de databasestructuur nauwkeurig bij te hou- 
den, is het correct gebruik van historische gegevens. Als de marketingafdeling bij- 
voorbeeld een analyse wil uitvoeren van drie jaar oude verkoopgegevens, die al twee 
jaar in een historisch bestand zijn opgeslagen, is het noodzakelijk te weten welke 
structuur destijds in gebruik was. Verslagen die de wijzigingen in de structuur laten 
zien, kunnen worden gebruikt om die vraag te beantwoorden. Een soortgelijk geval 
doet zich voor als een zes maanden oude back-upkopie van gegevens moet worden 
gebruikt om een beschadigde database te repareren (dit mag normaal gesproken 
niet voorkomen, maar helaas…). De back-upkopie kan dan worden gebruikt om de 
database te reconstrueren in de toestand waarin ze was toen de back-up werd ge- 
maakt. Vervolgens kunnen transacties en structurele wijzigingen in chronologische 
volgorde worden uitgevoerd om de database weer in haar huidige staat te brengen. 
Figuur 9-2 geeft een overzicht van de taken van de DBA voor het beheer van de 
databasestructuur. 
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Deelnemen in ontwikkeling van database 
en applicaties 
e Ondersteuning bieden in specificatiefase en 
bij evaluatie van alternatieven 
* Een actieve rol spelen bij het ontwerpen en 
creëren van de database 
Faciliteren van wijzigingen in de databasestructuur 
* Zoeken naar oplossingen die voor alle gebruikers 
acceptabel zijn 
« Beoordelen van gevolgen van wijzigingen voor 
alle gebruikers 
« Het opzetten van een forum over het configuratiebeheer 
* Anticiperen op problemen na wijzigingen in 
de structuur 


e Bijhouden van documentatie 


Figuur 9-2 Verantwoordelijkheden van de DBA voor het beheer van de databasestructuur 


9.3 Concurrencybeheer 


Het is ook nodig maatregelen te nemen voor het concurrencybeheer. Concurrency is 
het gelijktijdig door verschillende gebruikers gebruikmaken van dezelfde database. 
Concurrencybeheer moet voorkomen dat het werk van de ene gebruiker het werk 
van een andere nadelig beïnvloedt. In sommige gevallen zorgen deze maatregelen 
ervoor dat een gebruiker hetzelfde resultaat krijgt in een systeem met verscheidene 
gebruikers als wanneer hij zou werken in een single-user-database. In andere geval- 
len betekent het dat het werk van de gebruiker wel wordt beïnvloed door anderen, 
maar op een berekende manier. 

In een orderinvoersysteem bijvoorbeeld moet een gebruiker na invoering van een 
order hetzelfde resultaat krijgen, of er nu geen of honderden andere gebruikers aan- 
wezig zijn. Maar wanneer een gebruiker een rapport wil afdrukken van de huidige 
inventarisstatus, moeten gegevenswijzigingen van andere gebruikers ook worden 
verwerkt, zelfs als er gevaar bestaat dat die wijzigingen later worden geannuleerd. 

Helaas is er niet één techniek die of mechanisme dat onder alle omstandigheden 
een volledig concurrencybeheer biedt. Aan elke techniek zijn nadelen verbonden. 
Een gebruiker kan bijvoorbeeld een erg goed concurrencybeheer realiseren door de 
gehele database te locken, maar dat houdt wel in dat verder geen enkele gebruiker 
op dat moment iets kan uitvoeren. Dit is een heel goede beveiliging, maar tegen een 
hoge prijs. We zullen nog zien dat er andere middelen bestaan die lastiger te pro- 
grammeren of uit te voeren zijn, maar meer verwerkingsflexibiliteit bieden. Er zijn 
ook middelen die een maximale verwerkingsflexibiliteit bieden, maar voor een lager 
niveau van concurrencybeheer zorgen. Tijdens het ontwerpen van multi-user-data- 
baseapplicaties zul je uit de verschillende alternatieven moeten kiezen. 
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9.3.1 De behoefte aan atomaire transacties 
In de meeste databaseapplicaties werken gebruikers met eenheden die we transac- 
ties noemen. We spreken ook wel van logical units of work (LUW’s). Een transactie 
(of LUW) is een reeks bewerkingen die op de database worden uitgevoerd zodat ze 
ofwel allemaal, of geen van alle succesvol worden uitgevoerd — in dat laatste geval 
blijft de database ongewijzigd. Een dergelijke transactie wordt soms wel atomair (on- 
deelbaar) genoemd, omdat de bewerkingen als één geheel worden uitgevoerd. 

Kijk eens naar de volgende reeks databasehandelingen die kunnen optreden als 
een nieuwe order wordt vastgelegd: 
1. Wijzig de klantrecord door OpenstaandBedrag te verhogen. 
2. Wijzig de verkoperrecord door OpenstaandeCommissie te verhogen. 
3. Voeg de nieuwe orderrecord toe aan de database. 


Stel dat de laatste stap mislukt, bijvoorbeeld omdat er onvoldoende geheugenruimte 
beschikbaar is. Je kunt je voorstellen dat daardoor heel wat problemen kunnen ont- 
staan. De klant krijgt een factuur voor een artikel dat nooit is geleverd en de verkoper 
ontvangt commissie voor een bestelling die nooit naar de klant is gezonden. Het is 
duidelijk dat deze drie handelingen als één geheel moeten worden uitgevoerd, dus 
allemaal wel of allemaal niet. 

In Figuur 9-3 worden de resultaten vergeleken van het uitvoeren van deze activi- 
teiten als een reeks onafhankelijke stappen (Figuur 9-3a) en als een atomaire trans- 
actie (Figuur 9-3b). Je ziet dat als stappen worden uitgevoerd op een atomaire manier 
en een van de stappen mislukt, geen wijzigingen in de database worden doorge- 
voerd. Merk verder op dat de opdrachten Start Transaction, Commit Transaction of 
Rollback Transaction door de applicatie moeten worden verstrekt om de grenzen van 


de transactielogica aan te geven. Meer over deze opdrachten lees je verderop in dit 
hoofdstuk en in hoofdstuk ro. 


9.3.2 Gelijktijdige transacties verwerken 

Als twee transacties op hetzelfde moment in een database worden verwerkt, spre- 
ken we van concurrency (letterlijk: gelijktijdig optreden). Voor de gebruikers lijkt het 
alsof de transacties gelijktijdig worden verwerkt, maar in werkelijkheid is dit niet het 
geval: de CPU van een computer kan maar één instructie tegelijk uitvoeren. Trans- 
acties zijn vaak met elkaar vervlochten. Dat houdt in dat het besturingssysteem de 
CPU met een bepaald interval laat schakelen tussen verschillende taken. Dit gebeurt 
zo snel dat twee gebruikers die naast elkaar zitten en gebruikmaken van dezelfde 
database, zullen denken dat de transacties gelijktijdig worden uitgevoerd. De twee 
transacties zijn in werkelijkheid echter met elkaar vervlochten. 
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_Voor_ „Actie _Na_ 
í En 
‚__ Klant START KLANT 
! Klantnr Ordernr Omschrijving _ Bedrag 1. Voeg nleuwe ordergegevens | Klantnr Ordemr Omschrijving _ Bedrag 
| [a23 |] 1000 | soo Basebaiis | S2400 } toe aan KLANT [123 |] 1000 [400 Basebaiis | S2400 
| 123 8000 | 250 Basketballs | S6500 
| 
|_ VERKOPER \ VERKOPER 
| 2. Voeg nieuwe ordergegevens 
Naam Totaal Commisie tegoed toe aan VERKOPER Naam Totaal Commisie tegoed 
NE: = 
Jansen |] 3200 | 320 | [Jansen [[ ssroo |___ so70} 
ORDERS \ ORDERS 
| Ordernr 3. Voeg nieuwe ORDER in Ordemr 
1000 | -- [1000 [_--- 
_2000 | --- |_2000 
| „3000 | [_3000_ 
[aooo | | |_4ooo | 
{5000 | -:- | | 125000) Ber | 
6000 | | ; [_6000 
(zooo | | STOP [7000 _ 
"VoL” *VOL* 
Den 
(a) 
Voor Transactie Na 
: = = 
Klant Begin transactie KLANT 
KI Hist 
Klantnr Ordernr Omschrijving Bedrag wiee edens EHKOOER Klantnr Ordemr _ Omschrijving Bedrag 
[123 ] 1000 _[ 400 Basebails | S2400 | || wijzig gegevens ORDER in (423 [[_ 1ooo [400 Basebals | S2400 | 
is IF geen fouten THEN 
| Bevestig transactie (COMMIT) 
Í ELSE 
VERKOPER Maak transactie ongedaan VERKOPER 
| (ROLLBACK) 
Naam Totaal Commisie tegoed ENDE Naam Totaal Commisie tegoed 
| [uansen [] s3200 | 320 | [vansen [[ s3200 S320 
ORDERS ORDERS 


Ordernr 


(b) 


Figuur 9-3 Noodzaak voor transactieverwerking: (a) fouten die optreden zonder transactie (b) atomaire trans- 
actie voorkomt fouten 


In Figuur 9-4 staan twee gelijktijdige taken afgebeeld. Gebruiker A leest item roo, 
wijzigt het en schrijft het opnieuw naar de database. Gebruiker B doet precies het- 
zelfde, maar voor item 200. De CPU verwerkt gebruiker A totdat een I/O-interrupt 
of een andere onderbreking voor gebruiker A wordt gegenereerd. Het besturings- 
systeem verschuift de aandacht van de CPU naar gebruiker B. De CPU verwerkt nu 
gebruiker B totdat een interrupt komt, waarna het besturingssysteem de CPU weer 
laat overschakelen naar gebruiker A. Voor de gebruikers lijkt de verwerking gelijktij- 
dig plaats te vinden, maar in werkelijkheid is die dus vervlochten. 
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Gebruiker A Gebruiker B 


1. Lees item 100. 
2. Wijzig item 100. 


1. Lees item 200. 
2. Wijzig item 200. 


3. Schrijf item 100. 3. Schrijf item 200. 


Verwerkingsvolgorde op databaseserver 


1. Lees item 100 voor A. 
2. Lees item 200 voor B. 
3. Wijzig item 100 voor A. 
4. Schrijf item 100 voor A. 
5. Wijzig item 200 voor B. 
6. Schrijf item 200 voor B. 


Figuur 9-4 Voorbeeld van gelijktijdige verwerking 


9.3.3 Het lost update-probleem 

De concurrency-situatie in Figuur 9-4 levert geen problemen op, omdat de gebrui- 
kers met verschillende gegevensitems werken. Maar wat gebeurt er als beide gebrui- 
kers bijvoorbeeld item roo willen gaan bewerken? Als gebruiker A vijf eenheden van 


item roo wil bestellen en gebruiker B wil drie eenheden van hetzelfde item bestel- 
len, ontstaat een probleem (zie Figuur 9-5). 


Gebruiker A Gebruiker B 


1. Lees item 100 1. Lees item 100 

(waarde is 10). (waarde is 10). 
2. Verminder waarde met 5. 2. Verminder waarde met 3. 
3. Schrijf item 100. 3. Schrijf item 100. 


Verwerkingsvolgorde op databaseserver 


„Lees item 100 voor A. 
„ Lees item 100 voor B. 
‚ Stel waarde in op 5 voor A. 


. Schrijf item 100 voor A. 
„ Stel waarde in op 7 voor B. 
. Schrijf item 100 voor B. 


Figuur 9-5 Het lost update-probleem 
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Gebruiker A leest de record van item roo in het computergeheugen. Volgens de re- 
cord zijn er tien artikelen in voorraad. Vervolgens leest gebruiker B dezelfde record 
in een ander gedeelte van het geheugen. Ook volgens deze record zijn er tien artike- 
len in voorraad. Nu neemt gebruiker A er vijf, verlaagt het aantal artikelen van tien 
naar vijf en herschrijft de record voor item roo. Vervolgens neemt gebruiker B drie 
artikelen, verlaagt het aantal tot zeven en herschrijft de record voor item roo. Vol- 
gens de database zijn er nu zeven items roo op voorraad. 

Nog eens in het kort: we zijn begonnen met een inventaris van tien. Gebruiker A 
trok daar vijf van af en gebruiker B trok er drie van af. Volgens de database zijn er 
nu echter nog zeven artikelen in voorraad. Dat klopt niet dus we hebben duidelijk 
een probleem. 

Beide gebruikers haalden gegevens op die op dat moment correct waren, maar 
toen gebruiker B de record las, beschikte gebruiker A al over een kopie die hij op het 
punt stond te wijzigen. Deze situatie beschrijven we als het lost update-probleem 
(‘het probleem van de verloren wijziging’) of het concurrent update-probleem. Een 
ander, soortgelijk probleem is het zogenaamde inconsistent read-probleem, waarbij 
gebruiker A gegevens leest die zijn verwerkt door een deel van een transactie van ge- 
bruiker B, met als resultaat dat gebruiker A onjuiste gegevens voor zijn neus krijgt. 

Een mogelijke oplossing voor dit concurrency-probleem is voorkomen dat twee of 
meer applicaties kopieën van eenzelfde record kunnen opvragen als die record door 
een of meer applicaties zal worden gewijzigd. Deze oplossing duiden we aan met de 
term resource locking. 


9.3.4 Resource locking 

Een van de manieren waarop problemen door gelijktijdige verwerking zijn te voor- 
komen, is door de data (tijdelijk) niet te delen. De gegevens die worden gewijzigd, 
worden dan (tijdelijk) gelockt. In Figuur 9-6 is de verwerkingsvolgorde te zien als 
gebruik wordt gemaakt van een lock-opdracht. Vanwege de lock moet de transactie 
van gebruiker B wachten totdat gebruiker A klaar is met de bewerking van de gege- 
vens van item roo. Wordt deze strategie gebruikt, dan kan gebruiker B de record van 
artikel roo pas lezen als gebruiker A klaar is met het wijzigen ervan. In dit voorbeeld 
wordt uiteindelijk als aantal 2 opgeslagen in de database, zoals het hoort (beginvoor- 
raad was 1o, A nam 5 en B nam 3, dus er zijn er nog 2 over). 


9,3.5 Lock-terminologie 
Locks kunnen op twee manieren worden geplaatst: automatisch door het DBMS of 
door een opdracht die vanaf een applicatie of querygebruiker aan het DBMS wordt 
gegeven. Locks die door het DBMS worden uitgevoerd, zijn impliciete locks. Locks 
die via een opdracht plaatsvinden, heten expliciete locks. Vrijwel alle locking is te- 
genwoordig impliciet. Het programma declareert het gewenste gedrag en het DBMS 
zal automatisch de overeenkomstige locks plaatsen. Je ziet verderop in dit hoofdstuk 
hoe je dat doet. 

In het voorgaande voorbeeld werden de locks aangebracht op rijen gegevens. 
Niet alle locks worden echter op dit niveau aangebracht. Sommige DBMS-producten 
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Gebruiker A Gebruiker B 


1. Lock item 100. 
2. Lees item 100. 


1. Lock item 100. 
2. Lees item 100. 


3. Verminder het met 3. 
4, Schrijf item 100. 


3. Verminder het met 5. 
4. Schrijf item 100. 


Verwerkingsvolgorde op de databaseserver 


„ Lock item 100 voor A. 
. Lees item 100 voor A. 
| „ Probeer item 100 te 
Transactie van/A locken voor B; gaat niet, dus } 
B moet wachten. 

. Stel waarde in op 5 voor A. 

. Schrijf item 100 voor A. 

„ Ontgrendel lock van A op Transactie van B 

item 100. 

. Lock item 100 voor B. 

. Lees item 100 voor B. 

‚ Stel waarde in op 2 voor B. 


„ Schrijf item 100 voor B. 
„ Ontgrendel lock van B op 
item 100. 


Figuur 9-6 Gelijktijdige verwerking met expliciete locks 


locken op groepen rijen uit een tabel, sommige op hele tabellen en weer andere op 
de hele database. De omvang van de lock geven we aan met de zogenoemde lock 
granularity. Locks met een grote granulariteit kunnen eenvoudig door het DBMS 
worden beheerd, maar zorgen wel vaak voor conflicten. Locks met een kleine granu- 
lariteit zijn lastiger te beheren (het DBMS moet veel meer details bijhouden en con- 
troleren), maar zorgen voor veel minder stagnatie. 

Locks variëren ook per type. Een exclusieve lock sluit het betreffende item voor 
elke andere bewerking af — geen andere transactie kan de gegevens lezen of wijzigen. 
Bij een shared lock kan het item wel door andere transacties worden gelezen, maar 
niet worden gewijzigd. 


9.3.6 Serialiseerbare transacties 

Als twee of meer transacties gelijktijdig worden verwerkt, moeten de resulterende 

gegevens in de database logisch consistent zijn met de resultaten die zouden zijn be- 

reikt als de transacties in willekeurige volgorde na elkaar waren uitgevoerd. Een der- 

gelijke opzet voor de verwerking van gelijktijdige transacties noemen we serializable. | 
Serializable zijn is onder andere te realiseren door de transactie met behulp van 

tweefaselocking te verwerken. Bij deze methode mogen transacties net zoveel locks 
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plaatsen als ze willen, maar zodra de eerste lock wordt vrijgegeven, kan er geen 
andere lock meer worden bijgeplaatst. Bij transacties is dus sprake van een groei- 
fase, waarin de locks worden verkregen, en een krimpfase, waarin de locks worden 
vrijgegeven. 

Een aantal DBMS-producten maakt gebruik van een speciaal geval van tweefa- 
selocking. Bij deze methode worden tijdens de transactie locks geplaatst, maar kan 
een lock pas worden vrijgegeven als een COMMIT- of ROLLBACK-opdracht wordt 
verstrekt. Deze aanpak kent meer beperkingen dan gewone tweefaselocking, maar is 
eenvoudiger te implementeren. 

Stel dat we een orderinvoertransactie willen verwerken die bestaat uit een object 
KLANTORDER met gegevens uit de tabellen KLANT, VERKOPER en ORDER. Om 
er zeker van te zijn dat er in de database geen anomalieën optreden als gevolg van 
concurrency-problemen, verstrekt de orderinvoertransactie waar nodig locks aan de 
tabellen KLANT, VERKOPER en ORDER, voert ze alle wijzigingen in de database 
door en geeft vervolgens alle locks vrij. 


9.3.7 Deadlock 

Locking lost een probleem op, maar creëert tegelijkertijd een ander probleem. Kijk 
maar eens wat er gebeurt als twee gebruikers twee artikelen uit een voorraad willen 
bestellen. Stel dat gebruiker A papier wil hebben en, als hij dat papier kan krijgen, 
wil hij ook nog potloden bestellen. Gebruiker B wil wat potloden bestellen en als dat 
lukt, ook graag papier hebben. Een mogelijke verwerkingsvolgorde staat in Figuur 
9-7 afgebeeld. 

In deze figuur bevinden gebruikers A en B zich in een zogeheten deadlock- 
situatie. Beide gebruikers wachten op vrijgave van door de andere persoon gelockte 
gegevens. 

Een deadlock is op verschillende manieren te voorkomen, bijvoorbeeld door het 
gebruikers toe te staan alle locks tegelijk aan te vragen. Als gebruiker A direct in het 
begin zowel het papier als de potloden had gelockt, was er nooit een deadlock opge- 
treden. Een andere manier om een deadlock te voorkomen, is door te eisen dat alle 
applicaties gegevens in dezelfde volgorde locken. 


Opmerking 

‘Lock de parent-rij altijd voor de child-rijen als er rijen worden verwerkt van tabellen met een parent- 
childrelatie” Dit beleid zal op zijn minst de kans verminderen dat er een deadlock optreedt, wat het DBMS 
soms zal besparen zich van deadlocked transacties te moeten herstellen. 


Vrijwel elk DBMS heeft algoritmen voor het breken van deadlocks, als deze toch 
optreden. Het DBMS moet om te beginnen opmerken dat er een deadlock is op- 
getreden. De gebruikelijke oplossing bestaat er dan uit een van de transacties te 
annuleren en de door deze transactie uitgevoerde wijzigingen uit de database te ver- 
wijderen. Varianten hiervan met Oracle en SQL Server vind je terug in de volgende 
twee hoofdstukken. 
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Gebruiker A Gebruiker B 


1. Lock papier. 1. Lock potloden. 
2. Neem papier. 2. Neem potloden. 


3. Lock potloden. 3. Lock papier. 


Verwerkingsvolgorde op databaseserver 


1. Lock papier voor A. 

2. Loek potloden voor B. 

3. Verwerk verzoeken A; schrijf papier-record. 
4. Verwerk verzoeken B; schrijf potlood-record. 


5. Laat A wachten op vrijgave potloden. 
6. Laat B wachten op vrijgave papier. 
** Locked ** 


Figuur 9-7 Deadlock 


9.3.8 Optimistische versus pessimistische locking 

Locks kunnen volgens twee verschillende strategieën worden geplaatst. Bij optimis- 
tische locking wordt ervan uitgegaan dat er geen conflict optreedt. Gegevens worden 
ingelezen, de transactie wordt verwerkt, wijzigingen worden uitgevoerd en ten slotte 
wordt een controle uitgevoerd om te zien of een conflict is opgetreden — als dat niet 
het geval is, dan is de transactie gereed. Als er wel een conflict is opgetreden, wordt 
de transactie herhaald totdat ze tot een goed einde is gebracht. Bij pessimistische 
locking wordt er juist wel van uitgegaan dat een conflict zal optreden. Eerst worden 
locks aangebracht, daarna wordt de transactie verwerkt en vervolgens worden de 
locks weer vrijgegeven. 

In Figuur 9-8 staan van beide strategieën voorbeelden voor een transactie die het 
aantal potloden in de PRODUCT-tabel met vijf vermindert. Figuur 9-8(a) toont opti- 
mistische locking. Eerst worden de gegevens ingelezen en wordt de huidige waarde 
van Aantal potloden opgeslagen in de variabele OudeAantal. De transactie wordt 
verwerkt en — we gaan ervan uit dat alles probleemloos verloopt — er wordt een lock 
voor PRODUCT geplaatst. De lock heeft mogelijk alleen betrekking op de rij met 
potloden, maar kan net zo goed een groter bereik hebben. Het principe is echter 
hetzelfde. Nadat een lock is geplaatst wordt een SQL-statement uitgevoerd om de 
rij potloden te wijzigen met de WHERE-constraint dat de huidige waarde van Aan- 
tal gelijk is aan OudeAantal. Als er geen andere transactie is die het Aantal van de 
potlodenrij heeft gewijzigd, zal deze UPDATE slagen. Als dat wel is gebeurd, zal het 
UPDATE-statement mislukken. De lock zal in beide gevallen worden vrijgegeven. Is 
de transactie mislukt, dan zal het proces herhaald worden tot de transactie kan wor- 
den voltooid zonder dat er conflicten optreden. 
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SELECT _PRODUCT.Naam, PRODUCT.Aantal 
FROM PRODUCT 
WHERE PRODUCT.Naam = ‘Potlood’ 


OudeAantal = PRODUCT.Aantal 

Set NieuweAantal = PRODUCT.Aantal - 5 

{verwerk transactie — onderneem exceptie-actie als NieuweAantal < 0, etc. 
Ervan uitgaande dat alles OK is:} 

LOCK PRODUCT {op een bepaald granulariteitsniveau} 


UPDATE PRODUCT 

SET PRODUCT.Aantal = NieuweAantal 

WHERE PRODUCT.Naam = ‘Potlood’ 
AND PRODUCT.Aantal = OudeAantal 


UNLOCK PRODUCT 
{controleer of wijziging succesvol was; zo niet, herhaal transactie} 


(a) optimistische locking 


LOCK PRODUCT 


SELECT __PRODUCT.Naam, PRODUCT.Aantal 
FROM PRODUCT 
WHERE PRODUCT.Naam = ‘Potlood’ 


Set OudeAantal = PRODUCT.Aantal - 5 
{verwerk transactie — onderneem exceptie-actie als NieuweAantal < 0, etc. 
Ervan uitgaande dat alles OK is: } 


UPDATE PRODUCT 
SET PRODUCT.Aantal = NieuweAantal 
WHERE PRODUCT.Naam = ‘Potlood’ 


UNLOCK PRODUCT 
{niet nodig om te controleren of wijziging succesvol was} 
(b) pessimistische locking 
Figuur 9-8 Optimistische versus pessimistische locking 
In Figuur 9-8(b) staat de logica voor dezelfde transactie maar nu met gebruik van 
pessimistische locking. In dat geval wordt er eerst een lock geplaatst voor PRODUCT 


voordat een andere bewerking wordt uitgevoerd. Vervolgens worden de waarden in- 


gelezen, de transactie wordt verwerkt, het UPDATE-statement wordt uitgevoerd en 
de PRODUCT-tabel wordt weer vrijgegeven. 
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Het voordeel van optimistische locking is dat de lock pas wordt geplaatst nadat de 
transactie is verwerkt — de lock bestaat dus veel korter dan bij pessimistische locking. 
Als de transactie ingewikkeld in elkaar zit of als het systeem langzaam is (bijvoor- 
beeld als de computer tegelijkertijd ook andere taken uitvoert of omdat de gebruiker 
een kop koffie haalt of de computer afsluit zonder de browser af te sluiten), is dat 
verschil in tijd nog veel groter. Dit is met name van belang als de lock een grote gra- 
nulariteit heeft, bijvoorbeeld als de gehele PRODUCT-tabel wordt vergrendeld. 

Het nadeel van optimistische locking is dat als er veel bewerkingen plaatsvinden 
op de rij met potloden, de transactie misschien vaak opnieuw moet worden uitge- 
voerd. Optimistische locking is dus niet zo'n goede oplossing voor transacties waar- 
bij veel activiteit optreedt voor een bepaalde rij (zoals het kopen van een populair 
aandeel). 

Het internet is algemeen gesproken nogal ongeorganiseerd en van gebruikers 
op het internet kun je daarom van alles verwachten, zoals het halverwege afbreken 
van transacties. Tenzij internetgebruikers zich dus ergens officieel hebben aange- 

meld (bijvoorbeeld bij een online effectenhandelaar), is optimistische locking de te 
verkiezen methode. Op intranetten ligt de keuze wat lastiger. Optimistische locking 
is waarschijnlijk nog steeds de betere methode, tenzij bepaalde kenmerken van de 
applicatie zorgen voor een grote activiteit in bepaalde rijen of als bepaalde applicatie- 
specificaties het opnieuw uitvoeren van transacties ongewenst maken. 


9.3.9 Lock-kenmerken declareren 

Het zal duidelijk zijn dat concurrencybeheer een ingewikkeld onderwerp is — het is 
moeilijk het niveau, het type en de plaatsing van de lock te bepalen. De optimistische 
locking-strategie is bovendien soms ook nog eens afhankelijk van welke transacties 
er op dat moment worden uitgevoerd en van wat deze transacties doen. Om deze en 
andere redenen verstrekken databaseapplicaties over het algemeen geen expliciete 
locks, maar markeren ze in plaats daarvan transactiegrenzen, waarna ze het type 
lock-gedrag declareren dat door het DBMS moet worden gebruikt. Het DBMS kan 
op die manier locks plaatsen en verwijderen en zelfs het niveau en het type van locks 
dynamisch veranderen. 

In Figuur 9-9 zijn voor de potloodtransactie de transactiegrenzen gemarkeerd 
met de statements BEGIN TRANSACTION, COMMIT TRANSACTION en ROLL- 
BACK TRANSACTION. Deze grenzen zijn vitale informatie die het DBMS nodig 
heeft om verschillende lock-strategieën te kunnen uitvoeren. Als de ontwikkelaar 
nu aangeeft (via een systeemparameter of een soortgelijk hulpmiddel) dat optimisti- 
sche locking moet worden gebruikt, plaatst het DBMS de locks impliciet op de juiste 
plaats voor die lock-stijl. Als de ontwikkelaar echter met pessimistische locking wil 
werken, plaatst het DBMS de locks impliciet op een andere plek. 


9.3.10 Consistente transacties 

Soms kom je in beschrijvingen van transacties de Engelstalige afkorting ACID te- 
gen. Een ACID-transactie is een transactie die atomair, consistent, geïsoleerd en 
duurzaam is (Atomic, Consistent, Isolated & Durable). De kenmerken atomair en 
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BEGIN TRANSACTION: 


SELECT PRODUCT.Naam, PRODUCT. Aantal 
FROM PRODUCT 
WHERE PRODUCT.Naam = ‘Potlood’ 


OudeAantal = PRODUCT.Aantal 
Set NieuweAantal= PRODUCT.Aantal - 5 


{verwerk deel van transactie — onderneem exceptie-actie als 
NieuweAantal < 0, etc} 


UPDATE PRODUCT 
SET PRODUCT.Aantal = NieuweAantal 
WHERE PRODUCT.Naam = ‘Potlood’ 


{ga door met verwerking transactie}... 


IF transactie op normale wijze voltooid THEN 
COMMIT TRANSACTION 

ELSE 
ROLLBACK TRANSACTION 

END IF 


Ga door met het verwerken van andere acties die geen onderdeel 
zijn van deze transactie .… 


Figuur 9-9 Transactiegrenzen markeren 


duurzaam zijn eenvoudig te definiëren. Je hebt net gezien dat bij een atomaire 
transactie alle of geen van de databasebewerkingen plaatsvinden. Bij een duurzame 
transactie zijn alle uitgevoerde wijzigingen permanent. Is een duurzame wijziging 
eenmaal uitgevoerd, dan is het de verantwoordelijkheid van het DBMS te garande- 
ren dat de wijziging systeemstoringen overleeft. 

De termen consistent en geïsoleerd zijn echter niet zo eenvoudig te definiëren als 
de termen atomair en duurzaam. Bekijk de volgende SQL-opdracht voor het wijzigen 
van gegevens: 


UPDATE KLANT 


SET Kengetal = '042' 
WHERE Postcode = '9805' 


Stel dat er 5oo.ooo rijen in de KLANT-tabel staan en dat 5oo daarvan Postcode 
‘9805’ hebben. Het zal dan even duren voordat het DBMS al die 5oo rijen heeft 
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opgespoord. Mogen andere transacties gedurende die tijd de velden Kengetal of 
Postcode in KLANT bijwerken? Als het SQL-statement consistent is, zijn dat soort 
wijzigingen niet toegestaan. De update zal van toepassing zijn op de reeks rijen zoals 
die bestond op het moment dat het SQL-statement begon. Een dergelijke consisten- 
tie noemen we consistentie op statementniveau. 

Bekijk nu eens de volgende transactie die twee SQL-wijzigstatements bevat: 


BEGIN TRANSACTION 


UPDATE KLANT 
SET Kengetal = '042' 
WHERE Postcode = '9805' 


lander transactiewerk) 

UPDATE KLANT 

SET Korting = 0,05 

WHERE Kengetal = '042' 

(ander transactiewerk)} 
COMMIT TRANSACTION 


Wat betekent consistent in dit verband? Consistentie op statementniveau houdt in 
dat elk statement op onafhankelijke wijze consistente rijen verwerkt, maar dat wij- 
zigingen van andere gebruikers in deze rijen zijn toegestaan tijdens de periode tus- 
sen de twee SQL-statements. Consistentie op transactieniveau betekent dat alle rijen 
die door een of beide SQL-statements worden beïnvloed, tegen wijzigingen zijn be- 
schermd gedurende de gehele transactie. 

Merk echter op dat consistentie op transactieniveau dermate sterk is dat een 
transactie haar eigen wijzigingen niet kan zien bij bepaalde implementaties hiervan. 
In dit voorbeeld kan het zijn dat het tweede SQL-statement niet ziet dat rijen door 
het eerste SQL-statement zijn gewijzigd. 

Als het dus gaat over het begrip consistent, moet je proberen te achterhalen welk 
type consistentie wordt bedoeld. Je moet je ook bewust zijn van het potentiële gevaar 
van consistentie op transactieniveau. 

Het begrip geïsoleerd vraagt wat meer uitleg. 


9.3.11 Isolatieniveau van transactie 
De term geïsoleerd heeft een aantal verschillende betekenissen. We moeten eerst een 
paar nieuwe termen definiëren voordat je deze betekenissen kunt begrijpen. 

Een dirty read treedt op als een bepaalde transactie een gewijzigde record inleest 
die nog niet in de database is uitgevoerd. Het gevaar van een dirty read is dat de nog 
niet uitgevoerde wijziging kan worden teruggedraaid. De transactie die de dirty read 
heeft uitgevoerd, zal in dat geval onjuiste gegevens verwerken. 

Non-repeatable read vindt plaats als een transactie bepaalde gegevens opnieuw 
inleest die in de tussentijd zijn aangepast of deels verwijderd door een andere ver- 
richte transactie. Phantom read treedt ten slotte op als een transactie bij het opnieuw 
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inlezen van bepaalde gegevens ontdekt dat tussentijds nieuwe rijen zijn ingevoegd 
door een andere verrichte transactie. 

In de SQL-standaard uit 1992 worden vier isolatieniveaus gedefinieerd, waarin 
wordt aangegeven welke van deze problemen mogen optreden. Het is de taak van de 
applicatieprogrammeur het type isolatieniveau op te geven zodat het DBMS op over- 
eenkomstige wijze locks kan plaatsen en beheren. 

In Figuur g-1o is te zien dat het isolatieniveau Read Uncommitted toestaat dat 
dirty reads, non-repeatable reads en phantom reads mogen plaatsvinden. Bij het iso- 
latieniveau Read Committed zijn dirty reads verboden. Het isolatieniveau Repeata- 
ble Reads staat geen dirty reads en non-repeatable reads toe en het isolatieniveau Se- 
rializable verbiedt alle drie de leesproblemen. 


Isolatieniveau 


Read Serializable 


Uncommitted 


Read 
Committed 


Repeatable 
Read 


| Dirty Read mogelijk niet mogelijk niet mogelijk niet mogelijk 
Probleem-| Nonrepeatable | mogelijk mogelijk niet mogelijk niet mogelijk 
type Read 


Phantom Read | mogelijk mogelijk mogelijk niet mogelijk 


Figuur 9-10 Overzicht van isolatieniveaus 


In het algemeen geldt: hoe meer beperkend het niveau, hoe lager de verwerkings- 
capaciteit. Daarbij moeten we aantekenen dat veel afhangt van de werklast en de 
structuur van de applicaties. In het volgende hoofdstuk zie je hoe SQL Server omgaat 
met isolatieniveaus. 


9.3.12 Cursortype 
Een cursor is een (aan)wijzer in een verzameling rijen. Cursors worden meestal ge- 
definieerd met SELECT-statements, bijvoorbeeld als volgt: 


DECLARE CURSOR TransCursor AS 
SELECT £# 
F ROM TRANSACTION 
WHERE _ Aankoopprijs > '10000' 


Zoals al in paragraaf 7.8 uitgelegd, kan een applicatie die een cursor heeft geopend 
deze cursor plaatsen op een van de rijen in de verzameling resultaten (de result set). 
De cursor wordt meestal op de eerste of de laatste rij geplaatst, maar er zijn ook an- 
dere mogelijkheden. 

Een transactie kan verscheidene cursors openen — na elkaar of tegelijkertijd. Ver- 
der mogen er twee of meer cursors in dezelfde tabel openstaan — direct in de tabel 
of via een SQL-view voor die tabel. Omdat cursors aardig wat geheugen opeisen, kan 
het gelijktijdig open hebben staan van veel cursors, zoals voor duizend gelijktijdige 
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transacties, veel CPU-verwerkingstijd en geheugenruimte vergen. Een manier om 
de cursoroverhead te verminderen, is — in gevallen waar dat kan — cursors met ver- 
minderde capaciteit te definiëren. 

In Figuur 9-11 zijn vier typen cursors weergegeven die in de Windows-omgeving 
worden gebruikt. (Cursortypen voor andere systemen zijn soortgelijk.) De eenvou- 
digste cursor is forward only. Met deze cursor kan de applicatie alleen vooruit in de 
recordset bewegen. Wijzigingen die door andere cursors binnen deze transactie en 
door andere transacties worden gemaakt, zijn alleen zichtbaar als ze optreden in 
rijen na de cursor. 


En 


Forward only [Applicatie kan alleen vooruit Wijzigingen gemaakt door andere 
bewegen in de recordset. cursors in deze transacties zijn 
alleen zichtbaar als ze optreden 
in rijen na de cursor. 
Statisch 


Figuur 9-11 Overzicht van cursortypen 


Commentaar 


Applicatie ziet de gegevens ai Wijzigingen die door deze cursor 
zoals ze eruitzagen toen de zijn gemaakt, zijn zichtbaar. 
cursor werd geopend. Wijzigingen van andere bronnen 
zijn onzichtbaar. Vooruit en 
achteruit schuiven toegestaan. 


Als de cursor wordt geopend, 
wordt er voor elke rij in de 
recordset een primaire 
sleutelwaarde opgeslagen. Als 
de applicatie een rij benadert, 
wordt de sleutel gebruikt om 
de huidige waarde voor de rij 
op te halen. 


Wijzigingen van elke bron zijn 
zichtbaar. Invoegingen van bronnen 
buiten deze cursor zijn onzichtbaar 
(er is voor hen geen sleutel in de 
keyset). Invoegingen van deze 
cursor verschijnen onderaan in de 
recordset. Verwijderingen van elke 
bron zijn zichtbaar. Wijzigingen in 
rijvolgorde zijn niet zichtbaar. Als 
het isolatieniveau dirty read is, zijn 
onverrichte wijzigingen en 
verwijderingen zichtbaar — anders 
zijn alleen verrichte wijzigingen en 
verwijderingen zichtbaar. 


Wijzigingen van elk type en 


Alle invoegingen, wijzigingen en 
vanuit elke bron zijn zichtbaar. 


verwijderingen in de 
recordsetvolgorde zijn zichtbaar. 
Als het isolatieniveau dirty read is, 
zijn onverrichte wijzigingen en 
verwijderingen zichtbaar — anders 
zijn alleen verrichte wijzigingen en 
verwijderingen zichtbaar. 


LE 
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De andere drie cursortypen zijn zogenaamde schuifbare (scrollable) cursors, omdat 
de applicatie vooruit en achteruit in de recordset kan bewegen. Een statische cursor 
maakt en verwerkt een momentopname van een relatie. Wijzigingen die met deze 
cursor worden gemaakt, kunnen door deze cursor worden gezien — wijzigingen uit 
andere bronnen zijn niet zichtbaar. 

Keyset-cursors combineren bepaalde functies van statische cursors met functies 
van dynamische cursors. Als de cursor wordt geopend, wordt een primairesleutel- 
waarde opgeslagen voor elke rij in de recordset. Als de applicatie de cursor in een 
rij plaatst, gebruikt het DBMS deze waarde om de huidige waarde van de rij uit te 
lezen. Als de applicatie een rij wil wijzigen die door een andere cursor in deze trans- 
actie of door een andere transactie is verwijderd, creëert het DBMS een nieuwe rij 
met de oude sleutelwaarde en plaatst de gewijzigde waarden in de nieuwe rij (ervan 
uitgaande dat alle benodigde rijen aanwezig zijn). Tenzij het isolatieniveau van de 
transactie een dirty read is, zijn alleen verrichte wijzigingen en verwijderingen voor 
de cursor zichtbaar. 

Een dynamische cursor is een volledig uitgeruste cursor. Alle invoegingen, wijzi- 
gingen en verwijderingen in rijvolgorde zijn zichtbaar voor deze cursor. Net als bij 
keyset-cursors zijn alleen verrichte wijzigingen zichtbaar, tenzij het isolatieniveau 
van de transactie een dirty read is. 

De hoeveelheid overhead en verwerking die vereist is om een cursor te ondersteu- 
nen, varieert per type. In het algemeen betalen we een hogere prijs naarmate we la- 
ger in de tabel in Figuur g-11 komen. Om de verwerkingssnelheid van het DBMS te 
verbeteren, moet de applicatieprogrammeur dus cursors maken die het werk precies 
aankunnen. Het is verder belangrijk te weten hoe een bepaald DBMS cursors imple- 
menteert en of er cursors op de server en/of client staan. In bepaalde gevallen is het 
beter een dynamische cursor op de client te plaatsen dan een statische cursor op de 
server te hebben. Er bestaan geen algemene regels, omdat de verwerkingssnelheid 
afhangt van de implementatie van het DBMS-product en de applicatiespecificaties. 

Een waarschuwing: als je het isolatieniveau van een transactie niet opgeeft, of 
als je niet aangeeft welk type cursor moet worden geopend, zal het DBMS een stan- 
daardniveau gebruiken. Dat kan toevallig goed uitpakken, maar ook heel slecht. Je 
kunt deze onderwerpen weliswaar negeren, maar je kunt de consequenties ervan 
niet vermijden. Verdiep je daarom vooraf in de mogelijkheden van jouw DBMS-pro- 
duct en maak daar verstandig gebruik van. 


9.4 _Databasebeveiliging 


Het doel van een databasebeveiliging is ervoor te zorgen dat alleen daartoe bevoeg- 
de gebruikers bepaalde activiteiten op bepaalde tijdstippen kunnen uitvoeren. Om 
dit mogelijk te maken, zal het databaseontwikkelteam al tijdens het opstellen van 
de specificaties verwerkingsrechten en -verantwoordelijkheden voor alle gebruikers 
moeten vaststellen. Deze eisen kunnen vervolgens worden opgelegd met behulp van 


de beveiligingsfaciliteiten van het DBMS en aanvullingen daarop die zijn geschreven 
in applicaties. 
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9.4.1 Verwerkingsrechten en -verantwoordelijkheden 

Als we even terugkijken naar de specificaties van galerie View Ridge, zien we dat er 
drie typen gebruikers zijn: verkopers, management en DBA's. Het verkooppersoneel 
mag nieuwe klant- en transactiegegevens invoeren, klantgegevens wijzigen en alle 
gegevens raadplegen. Ze mogen geen gegevens invoeren over nieuwe kunstenaars 
of kunstwerken en ze mogen geen gegevens verwijderen. 

Het managementpersoneel mag alles doen wat de verkopers mogen doen en ze 
mogen nieuwe kunstenaars en werken invoeren en transactiegegevens aanpassen. 
Ze mogen weliswaar ook gegevens verwijderen, maar in deze applicatie wordt hun 
daarvoor geen permissie verstrekt om te voorkomen dat per ongeluk gegevens ver- 
loren gaan. 

De DBA heeft onbeperkte toegang tot de gegevens. Hij of zij mag alle gegevens 
in de database creëren, wijzigen, lezen en verwijderen. De DBA kan tevens ver- 
werkingsrechten aan andere gebruikers verstrekken en de structuur van database- 
elementen wijzigen zoals tabellen, indexen en opgeslagen procedures. Figuur 9-12 


geeft een overzicht van wie wat mag doen. 
Work Je 
Opvragen Opvragen 


Invoegen, 


Transaction 


Verkopers 


Invoegen, 
wijzigen, opvragen 


Invoegen, 
opvragen 


Management- | Invoegen, 


Invoegen, wijzigen, 
opvragen 


Invoegen, 


personeel wijzigen, opvragen wijzigen, opvragen |wijzigen, opvragen 


Rechten toekennen, 


Rechten toekennen, | Rechten toekennen, [Rechten toekennen, 
structuur wijzigen 


structuur wijzigen structuur wijzigen structuur wijzigen 


Figuur 9-12 Verwerkingsrechten bij galerie View Ridge 


De permissies uit deze tabel worden normaliter niet aan afzonderlijke mensen toe- 
gekend maar aan groepen mensen. Deze groepen worden soms rollen genoemd, 
omdat ze mensen beschrijven die een bepaalde taak of rol hebben. Soms wordt ook 
de term gebruikersgroepen gehanteerd. Het is gebruikelijk, maar niet vereist, om 
permissies aan rollen (of gebruikersgroepen) toe te kennen. Het is bijvoorbeeld mo- 
gelijk om te zeggen dat gebruiker ‘Ben Fransen’ bepaalde verwerkingsrechten heeft. 
Verder is het zo dat als er groepen worden gebruikt, er hulpmiddelen aanwezig moe- 
ten zijn om gebruikers aan die groepen toe te kennen. Als ‘Marie Smit’ zich aan- 
meldt op haar computer, moet er een manier zijn om te bepalen welke rol of rollen 
zij heeft. In de volgende paragraaf gaan we hier verder op in. 

We hebben het zojuist gehad over verwerkingsrechten en -verantwoordelijk- 
heden. Verantwoordelijkheden gaan dus samen met bepaalde verwerkingsrechten. 
Als de DBA bijvoorbeeld transactiegegevens verwijdert, heeft hij of zij ook tegelijker- 
tijd de verantwoordelijkheid ervoor te zorgen dat deze verwijderingen geen nadelige 
invloed hebben op het beheer van de galerie, de boekhouding, enzovoort. 
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Verwerkingsverantwoordelijkheden kunnen niet door het DBMS of door databaseap- 
plicaties worden opgelegd. Ze worden daarom gecodeerd in handmatige procedures 
en aan gebruikers apart uitgelegd tijdens een systeemopleiding. Dit zijn onderwer- 
pen die bij de systeemontwikkeling thuishoren — het enige wat we er hier over zeggen 
is dat verantwoordelijkheden hand in hand gaan met bepaalde rechten. Dergelijke 
verantwoordelijkheden moeten worden gedocumenteerd en gehandhaafd. 

Volgens Figuur g-r heeft de DBA onder andere als taak verwerkingsrechten en 
-verantwoordelijkheden te beheren. Deze rechten en verantwoordelijkheden veran- 
deren in de loop van de tijd. Tijdens het gebruik van de database worden wijzigingen 
aangebracht in de applicaties en de DBMS-structuur, waardoor de behoefte ontstaat 
nieuwe rechten en verantwoordelijkheden op te stellen of bestaande aan te passen. 
De DBA is een centrale figuur bij de bespreking van dergelijke wijzigingen en bij de 
implementatie ervan. 

Als de verwerkingsrechten eenmaal zijn gedefinieerd, kunnen ze op verschil 
lende niveaus worden geïmplementeerd: besturingssysteem, netwerk, webserver, 
DBMS en applicatie. In de volgende twee paragrafen bekijken we rechten op DBMS- 
en applicatieniveau. De andere vallen buiten het kader van dit boek 


9.4.2 DBMS-beveiliging 

De terminologie, functies en mogelijkheden van DBMS-beveiliging zijn afhanke- 
lijk van het gebruikte DBMS-product. In feite bieden alle producten faciliteiten die 
specifieke bewerkingen op bepaalde objecten voor bepaalde gebruikers beperken. In 
Figuur 9-13 is een algemeen model afgebeeld van DBMS-beveiliging. Aan een USER 
kunnen een of meer ROLEs (of USER GROUPS) worden toegekend en een ROLE 
kan een of meer USERs hebben. Een OBJECT is een item van een database, zoals 
een tabel, een view of een opgeslagen procedure. PERMISSION is een associatie- 
entiteit tussen USER, ROL en OBJECT. De relaties van USER naar PERMISSION, 
van ROL naar PERMISSION en van OBJECT naar PERMISSION zijn dan ook alle- 
maal r:N, M-O. 


Richard van de Ent 
Ellie Wu Boekhouding kan KLANT-tabel wijzigen 


Johan Jacobs Ellie Wu kan MaandEind-applicatie uitvoeren 
Johan Jacobs mag alle tabellen wijzigen 


Procedure 
Boekhouding Applicatie 
Loketbedienden 
Winkelbedienden 


Onbekend publiek 
Figuur 9-13 Verwerkingsrechten bij galerie View Ridge 
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Als een gebruiker zich bij de database aanmeldt, beperkt het DBMS zijn of haar 
mogelijkheden tot de permissies die voor die gebruiker zijn gedefinieerd en tot per- 
missies voor rollen waaraan die gebruiker is toegewezen. Alle commerciële DBMS- 
producten gebruiken een of andere versie van gebruikersnaam en wachtwoord, 
hoewel deze vorm van beveiliging soms vrij eenvoudig te omzeilen is als gebruikers 
niet zorgvuldig met hun gegevens omspringen. 

Gebruikers kunnen hun naam en wachtwoord invoeren. De gebruikersnaam en 
het wachtwoord van Windows zijn soms direct te koppelen aan SQL Server. 

Internetapplicaties definiëren meestal een groep, zoals ‘Unknown Public’, en 
kennen anonieme gebruikers toe aan die groep als zij zich aanmelden. Op deze ma- 
nier hoeven bedrijven als Dell niet elke potentiële klant met naam en wachtwoord in 
hun beveiligingssysteem in te voeren. De beveiligingssystemen van Oracle en SQL 
Server zijn varianten van het model in Figuur 9-13. Je leest meer hierover in hoofd- 
stuk ro en 11. 


9.4.3 Richtlijnen voor DBMS-beveiliging 

Figuur 9-14 toont richtlijnen voor het verbeteren van de beveiliging van databasesys- 
temen. Het DBMS moet om te beginnen altijd achter een firewall worden uitgevoerd. 
De DBA moet er bij het plannen echter van uitgaan dat de firewall is doorbroken. 


Het DBMS, de database en alle applicaties moeten altijd veilig zijn, zelfs als de fire- 
wall faalt. 


me 


« Plaats DBMS achter een firewall, maar plan alsof de firewall is te doorbreken. 
e Pas het nieuwste besturingssysteem en de nieuwste DBMS-servicepacks en -fixes toe. 
« Gebruik het minimum aan functionaliteit: 
® Ondersteun zo weinig mogelijk netwerkprotocollen. 
* Verwijder overbodige of ongewenste opgeslagen systeemprocedures. 
* Schakel zo mogelijk standaardaanmeldingen en gastgebruikers uit. 
e Sta het gebruikers nooit toe zich interactief bij het DBMS aan te melden, 
tenzij dat echt nodig is. 
e Bescherm de computer die het DBMS uitvoert: 
« Geen enkele gebruiker mag met de computer werken die het DBMS uitvoert. 
« De DBMS-computer moet fysiek beveiligd zijn achter gesloten deuren. 
» Bezoeken aan de DBMS-computerruimte moeten in een logboek worden 
geregistreerd. 
e Beheer accounts en wachtwoorden: 
e Gebruik een gebruikersaccount met weinig rechten voor de DBMS-service. 
e Bescherm databaseaccounts met sterke wachtwoorden. 
e Houd mislukte aanmeldpogingen in de gaten. 
e Controleer regelmatig het lidmaatschap van groepen en rollen. 
e Zoek naar accounts zonder wachtwoorden. 
e Ken de laagst mogelijke privileges toe aan accounts. 
e Beperkt de toegangsprivileges van de DBA. 
e Planning: 
e Ontwikkel een beveiligingsplan voor het voorkomen en opmerken van 
beveiligingsproblemen. 
e Ontwikkel procedures voor noodgevallen en oefen deze. 


Figuur 9-14 Samenvatting van richtlijnen voor DMBS-beveiliging 
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Leveranciers van DBMS-systemen, waaronder Oracle en Microsoft, voegen voort- 
durend mogelijkheden toe aan hun producten die de beveiliging verbeteren en die 
de kwetsbaarheid van hun producten verminderen. Organisaties die DBMS-produc- 
ten gebruiken, moeten daarom geregeld op de websites van de leveranciers nazien of 
er nieuwe service packs en fixes zijn — service packs en alle probleemoplossingen die 
te maken hebben met beveiligingskenmerken en -functies en de verwerking, moe- 
ten zo snel mogelijk worden geïnstalleerd. 

Het installeren van nieuwe service packs en fixes is niet zo eenvoudig als dat hier 
wordt beschreven. Het installeren van een service pack of een fix kan bepaalde ap- 
plicaties breken — vooral als het om commerciële software gaat die vereist dat bepaal- 
de, specifieke service packs en fixes geïnstalleerd (of juist niet geïnstalleerd) zijn. Je 
moet misschien met het installeren van DBMS-service packs wachten tot de leveran- 
ciers van commerciële software hun producten aan de nieuwe versies hebben aange- 
past. Alleen al de mogelijkheid dat een bepaalde commerciële applicatie zou kunnen 
falen na het toepassen van een DBMS-service pack of -fix kan al voldoende reden zijn 
om het installeren van de fix uit te stellen. Het DBMS zal dan echter kwetsbaar zijn 
gedurende deze periode. Je zult zelf moeten kiezen waar je spijt van wilt hebben. 

Databasekenmerken en functies die niet nodig zijn voor de applicaties moeten 
bovendien uit de DBMS-producten worden verwijderd, of ze moeten uitgeschakeld 
worden. Wordt bijvoorbeeld TCP/IP gebruikt voor het opnemen van verbinding met 
het DBMS, dan moeten alle andere communicatieprotocollen worden verwijderd. 
Deze actie vermindert het aantal manieren waarop niet-geautoriseerde activiteit het 
DBMS kan bereiken. Alle DBMS-producten installeren verder opgeslagen systeem- 
procedures die services leveren, zoals het starten van een opdrachtenbestand, het 
wijzigen van het systeemregister en het versturen van e-mail. Alle opgeslagen pro- 
cedures die niet nodig zijn voor de applicaties moeten worden verwijderd. Zijn alle 
gebruikers bekend bij het DBMS, dan moeten standaardaanmeldingen en gastac- 
counts worden verwijderd. Het mag de gebruikers ten slotte nooit worden toege- 
staan zich in de interactieve modus bij het DBMS aan te melden, tenzij dat werkelijk 
vereist is. De gebruikers moeten altijd via een applicatie toegang tot de database 
krijgen. 

Verder moet de computer waarop het DBMS wordt uitgevoerd, worden bevei- 
ligd. Alleen geautoriseerd DBA-personeel mag toestemming krijgen via het toetsen- 
bord te werken met de machine waarop het DBMS wordt uitgevoerd. De computer 
waarop het DBMS wordt uitgevoerd, moet fysiek beveiligd worden door deze achter 
gesloten deuren te plaatsen. Er moet toezicht zijn op de toegang tot deze locatie. Elk 
bezoek aan de DBMS-computerruimte moet in een logboek worden geregistreerd. 

Accounts en wachtwoorden moeten nauwgezet worden toegekend en voort- 
durend worden beheerd. Het DBMS zelf moet onder een account werken die de 
laagst mogelijke systeemprivileges heeft. Een indringer die erin slaagt toegang tot 
het DBMS te krijgen, heeft op die manier slechts een beperkte autoriteit op deze lo- 
kale computer of op het netwerk. Alle accounts van het DBMS moeten verder wor- 
den beveiligd met sterke wachtwoorden. Dergelijke wachtwoorden zijn minstens acht 
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tekens lang en omvatten hoofd- en kleine letters, cijfers, speciale tekens (zoals +, @, 
#, *ik) en niet-afdrukbare tekens (bepaalde toetsencombinaties met Alt). 

De DBA moet de aan groepen en rollen toegekende accounts regelmatig controle- 
ren om te verzekeren dat alle accounts en rollen bekend en geautoriseerd zijn en dat 
ze de juiste permissies hebben. De DBA moet bovendien controleren op accounts 
zonder wachtwoorden. Van de gebruikers van dergelijke accounts moet worden ge- 
eist dat ze hun accounts beveiligen met sterke wachtwoorden. Ook de algemene re- 
gel dat de laagst mogelijke privileges aan accounts worden toegekend, moet worden 
aangehouden. 

Tot de privileges van de DBA behoort normaliter niet het recht om gebruikersge- 
gevens te verwerken. Mocht de DBA zichzelf dat privilege geven, dan zal deze niet- 
geautoriseerde toekenningsbewerking in het databaselogbestand te zien zijn. 

De worm Slammer infecteerde in het voorjaar van 2003 duizenden sites die met 
SQL Server werkten. Microsoft had al voor die tijd een patch voor SQL Server uitge- 
bracht die deze infectie voorkwam. Sites die deze patch hadden geïnstalleerd, had- 
den geen problemen. De moraal van het verhaal is dus dat je beveiligingspatches 
voor je DBMS altijd zo snel mogelijk moet installeren. Stel een procedure op om 
regelmatig te controleren of er dergelijke patches zijn. 

De DBA moet ten slotte deelnemen aan het plannen van de beveiliging. Er moe- 
ten procedures worden ontwikkeld voor zowel het voorkomen als het opmerken van 
beveiligingsproblemen. Ook zijn er procedures nodig voor de acties die moeten wor- 
den ondernomen in het geval de beveiliging wordt doorbroken. Deze procedures 
moeten ook in de praktijk worden toegepast. 

Het belang van de beveiliging van informatiesystemen is sterk toegenomen in 
de afgelopen jaren. DBA-personeel moet regelmatig op het web in het algemeen en 


specifiek op de websites van de leveranciers van hun DBMS-producten naar beveili- 
gingsinformatie zoeken. 


9.4.4 Applicatiebeveiliging 

DBMS-producten zoals Oracle en SQL Server voorzien dan wel in functies en moge- 
lijkheden voor de beveiliging van de database, maar die zijn meestal vrij algemeen 
van aard. Als de applicatie om specifieke beveiligingsmaatregelen vraagt zoals ‘Geen 
enkele gebruiker mag een rij van een tabel of van een join van een tabel bekijken 
waarin een naam van een medewerker staat die anders is dan zijn of haar eigen 
naam’, zijn de DBMS-faciliteiten ontoereikend en moet het beveiligingssysteem wor- 
den uitgebreid met functies in de databaseapplicatie. 

Je zult bijvoorbeeld in hoofdstuk 12 zien dat de beveiliging van internetapplica- 
ties vaak door de webservercomputer wordt geleverd. Het uitvoeren van applicatie- 
beveiliging op deze server betekent dat er geen gevoelige gegevens over het netwerk 
verstuurd hoeven te worden. 

Laten we daar nog eens nader op ingaan. Stel dat er een applicatie is geschreven 
die de volgende query naar de webserver en vandaar naar het DBMS verstuurt als de 
gebruiker in zijn browser op een bepaalde knop klikt: 
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SBBECT 
FROM WERKNEMER; 


Door dit statement worden alle rijen van de WERKNEMER-tabel teruggegeven. 
Als het applicatiebeveiligingsbeleid als beperking oplegt dat werknemers alleen 
hun eigen gegevens kunnen benaderen, kan een webserver een WHERE-bepaling 
toevoegen: 


SEEC £ 
FROM WERKNEMER; 
WHERE WERKNEMER. Naam = '<%=SESSION( “Medewerkernaam”)%)' 


Een dergelijke expressie heeft tot gevolg dat de webserver de naam van de medewer- 
ker in de WHERE-constraint invult. Voor een gebruiker die is aangemeld onder de 
naam ‘Ben Fransen’ is het resulterende statement uit deze expressie: 


SEBECT » # 
FROM WERKNEMER; 
WHERE WERKNEMER.Naam = ‘Ben Fransen’; 


Omdat de naam wordt ingevoegd door een programma op de webserver, weet 
de browsergebruiker niet dat dit plaatsvindt en kan hij deze bewerking dus niet 
belemmeren. 

Een dergelijke beveiligingsverwerking kan niet alleen worden uitgevoerd op een 
webserver, maar ook binnen applicaties zelf. Ze kan ook worden geschreven als op- 
geslagen procedures of triggers die op bepaalde tijdstippen door het DBMS worden 
uitgevoerd. 

Dit idee is uit te breiden door extra gegevens op te slaan in een beveiligingsdata- 
base die kan worden benaderd via de webserver of door opgeslagen procedures en 
triggers. Zo'n beveiligingsdatabase bevat bijvoorbeeld de identiteit van gebruikers, 
gekoppeld aan extra waarden van WHERE-statements. Veronderstel dat de gebrui- 
kers op Personeelszaken behalve hun eigen gegevens ook die van anderen kunnen 
benaderen. De gegevens voor de betreffende WHERE-statements kunnen in de be- 
veiligingsdatabase worden opgeslagen, door de applicatie worden gelezen en eventu- 
eel aan SELECT-statements worden toegevoegd. 

In het algemeen moet je echter in eerste instantie gebruikmaken van de func- 
ties die de DBMS-beveiliging biedt — alleen als die ontoereikend blijken, kun je daar 
zaken aan toevoegen met aparte toepassingscode. Hoe dichter bij de gegevens de 
beveiliging wordt uitgevoerd, des te kleiner de kans op infiltratie van die gegevens. 
Bovendien is het gebruik van faciliteiten die door de DBMS-beveiliging worden ge- 
boden sneller en goedkoper en zijn de resultaten beter dan bij apart ontwikkelde 
applicaties. 
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9.4.5 SQL injection-aanval 
Als gegevens van de gebruiker worden gebruikt voor het wijzigen van een SQL-op- 
dracht, bestaat telkens de mogelijkheid dat er een zogenoemde SQL injection-aanval 
plaatsvindt. Zou de naam van de medewerker in de vorige paragraaf via een web- 
formulier worden verkregen, in plaats van via een beveiligde manier zoals via het 
besturingssysteem, dan bestaat de kans dat de gebruiker SQL in de opdracht kan 
‘injecteren’, 

Stel bijvoorbeeld dat gebruikers hun naam invullen in een tekstvak in een web- 
formulier. Stel nu dat de gebruiker de waarde Frits Jansen ‘OR TRUE’ invult als zijn 
of haar naam. De toepassing genereert dan de volgende SQL-opdracht: 


SEBECTE 
FROM WERKNEMER; 
WHERE WERKNEMER.Naam = ‘Frits Jansen! OR TRUE; 


De waarde TRUE is altijd waar voor elke rij, zodat elke rij van de tabel WERKNEMER 
zal worden geleverd! 

De invoer van een gebruiker waarmee een SQL-opdracht wordt gewijzigd, moet 
dus altijd nauwgezet worden bewerkt om zeker te stellen dat alleen geldige invoer 
wordt aangenomen en er geen extra SQL-syntaxis is ingevoerd. 


9.5 _Database-recovery 


Computersystemen falen. Hardware gaat stuk. Programma's bevatten fouten. Door 
mensen ontwikkelde procedures bevatten fouten en mensen maken zelf ook fouten. 
Omdat een database wordt gedeeld door veel mensen en omdat een database een be- 
langrijke plaats inneemt binnen een organisatie, is het belangrijk dat die fouten snel 
worden hersteld. 

Er moeten verschillende problemen worden aangepakt. Ten eerste is het vanuit 
zakelijk oogpunt belangrijk dat het werk doorgaat. Klantorders, financiële transac- 
ties en paklijsten zullen bijvoorbeeld met de hand moeten worden opgesteld. Later, 
als de databaseapplicatie weer normaal functioneert, kunnen de nieuwe gegevens 
alsnog worden ingevoerd. Ten tweede moet het systeem zo snel mogelijk weer in 
een bruikbare toestand worden gebracht, die zo dicht mogelijk in de buurt ligt bij de 
toestand zoals die was toen het systeem vastliep. Ten derde moeten gebruikers we- 
ten wat ze moeten doen als het systeem weer in de lucht is. Sommige bewerkingen 
moeten misschien opnieuw worden uitgevoerd en gebruikers moeten weten hoe ver 
terug ze moeten gaan. 

Als er fouten in het systeem optreden, is het onmogelijk het probleem op te los- 
sen en verder te gaan alsof er niets is gebeurd. Zelfs als tijdens de storing geen gege- 
vens verloren zijn gegaan, is het domweg onmogelijk de klok terug te draaien en alle 
elektronen in precies de configuratie terug te brengen die ze innamen toen de fout 
optrad. Er bestaan echter wel twee procedures die de schade zo goed mogelijk her- 
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stellen. De eerste recovery-procedure die we bespreken, is recovery via reprocessing. 
De tweede is recovery via rollback/rollforward. 


9.5.1 Database-recovery via reprocessing 

Het is niet mogelijk het systeem in precies dezelfde toestand te brengen als waarin 
het zich bevond toen de storing optrad. Wat we wel kunnen doen, is teruggaan naar 
een bekend punt en de verwerking vanaf daar weer oppakken. De meest eenvoudige 
vorm van dit type recovery bestaat uit het regelmatig kopiëren van de database (dit 
noemen we een database save) en het bijhouden van een status van alle transacties 
die sindsdien zijn uitgevoerd. Als dan een fout optreedt, kan de database worden 
hersteld vanaf de laatste save, waarna alle transacties sinds die save opnieuw kunnen 
worden uitgevoerd. 

Helaas is deze eenvoudige strategie in de meeste gevallen niet toepasbaar, omdat 
het opnieuw uitvoeren van die laatste transacties net zoveel tijd in beslag neemt als 
toen ze voor de eerste keer werden verwerkt. Als de computer drukbezet is, kan het 
zijn dat het systeem ‘zichzelf nooit inhaalt’, omdat er steeds meer nieuwe transacties 
bijkomen. 

Ten tweede vinden taken die gelijktijdig worden verwerkt in een multi-user-sys- 
teem op asynchrone wijze plaats. De kleinste afwijking in menselijke handelingen, 
bijvoorbeeld als een gebruiker een e-mail leest voordat op een prompt wordt gere- 
ageerd, kan de volgorde waarin de opeenvolgende transacties worden uitgevoerd al 
veranderen. Zo kan het voorkomen dat klant A oorspronkelijk de laatste stoel op een 
bepaalde vlucht kreeg toegewezen, maar dat bij het opnieuw uitvoeren van de bewer- 
kingen nadat de storing is opgelost, klant B de gelukkige is. Recovery via reproces- 
sing is daarom meestal geen geschikte oplossing. 


9.5.2 Recovery via rollback/rollforward 

Een tweede methode is regelmatig een kopie van de database (de database-save) ma- 
ken en een logbestand bijhouden met wijzigingen die transacties in de database uit- 
voerden sinds de save. Als dan een storing optreedt, kan een van de volgende twee 
methoden worden ingezet. Bij de eerste methode, recovery via rollforward, wordt de 
database hersteld met behulp van de opgeslagen gegevens, waarna alle geldige, in 
het log verwerkte wijzigingen sinds de save opnieuw worden uitgevoerd. (De trans- 
acties worden dus niet opnieuw verwerkt, zoals bij reprocessing het geval is, omdat 
de applicaties niet bij de rollforward betrokken zijn.) 

De tweede methode is recovery via rollback. Bij deze methode worden wijzigin- 
gen ongedaan gemaakt die door foutieve of slechts deels uitgevoerde transacties zijn 
gemaakt door ze uit de database te verwijderen. Vervolgens worden de geldige trans- 
acties die in bewerking waren ten tijde van de storing, opnieuw gestart. 

Bij beide methoden is een log of logbestand noodzakelijk, waarin de resultaten 
van de transacties worden bewaard. In een log worden de gegevenswijzigingen in 
chronologische volgorde opgeslagen. Transactieresultaten worden eerst naar het log 
geschreven voordat ze ook werkelijk in de database worden geplaatst. Dat betekent 
dat het ergste geval, namelijk als het systeem vastloopt in de periode tussen het 
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loggen van een transactie en het vastleggen van het resultaat in de database, alleen 
inhoudt dat er een transactie is geregistreerd die nog niet in de database is opgeno- 
men. Zou het omgekeerde het geval zijn, dus als de transacties in de database zou- 
den worden geplaatst voordat deze wordt gelogd, dan bestaat de kans dat de database 
is gewijzigd zonder dat daarvan een log is bijgehouden. Een onoplettende gebruiker 
zou in dat geval een al verwerkte transactie nogmaals kunnen invoeren. 

Als een storing optreedt, wordt de log zowel gebruikt om transacties ongedaan 
te maken als opnieuw uit te voeren (zie Figuur 9-15). Om een transactie terug te 
draaien, moet de log een kopie bevatten van de waarden van elke databaserecord (of 
pagina) van vóór de wijziging. Zulke records noemen we ook wel before images. Een 
transactie wordt ongedaan gemaakt door de before images van alle wijzigingen in de 
database terug te zetten. 


Database met 


Database zonder 
wijzigingen 


wijzigingen 


Before images 


(a) 


Database zonder 
wijzigingen 
(save) 


Opnieuw 
uitvoeren 


Database met 
wijzigingen 


After images 


(b) 
Figuur 9-15 Transacties ongedaan maken en opnieuw uitvoeren met (a) rollback en (b) rollforward 
Om een transactie opnieuw uit te voeren, moet de log een kopie hebben van de waar- 


den van elke databaserecord (of pagina) van ná de wijziging. Deze records noemen we 
after images. Een transactie wordt herhaald door alle after images opnieuw naar de 
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database te kopiëren. In Figuur g-16 staat een aantal mogelijke gegevenselementen 
vermeld die in een transactielogbestand worden opgenomen. 

In dit voorbeeldlogbestand heeft elke transactie een unieke naam waarmee de 
transactie wordt geïdentificeerd. Bovendien zijn alle images van een gegeven trans- 
actie aan elkaar gekoppeld via pointers. De achterwaartse pointer wijst naar de vorige 
wijziging die door deze transactie is uitgevoerd. De voorwaartse pointer wijst naar 
de volgende wijziging. Een nul in het pointerveld betekent het einde van de lijst. 
Het DBMS-recovery-subsysteem gebruikt deze pointers om alle records voor een 
bepaalde transactie op te sporen. In Figuur 9-16 zie je een voorbeeld van de inhoud 
van een logbestand. 


oort bewerking 


Relatief recordnummer 
ijd 


Voorwaartse pointer 
Before image 
After image 


Object 


5 Lp) 


MODIFY__| KLANT 100_| (oude waarde) 


START 


; 


COMMIT 
MODIFY 


VK BB 


oo 0 0E NARE NN + 


mk, 


Figuur 9-16 Voorbeeld van een transactielogbestand 


Andere gegevens die in het log zijn opgenomen, zijn: het tijdstip van iedere actie, 
het soort bewerking (START is het begin van een transactie, COMMIT beëindigt een 
transactie en geeft alle bijbehorende locks vrij), het object dat werd bewerkt, zoals 
recordtype en identifier, en de before en after images. 

Als we beschikken over een log met before en after images, zijn de handelingen 
voor het terugdraaien en opnieuw uitvoeren vrij eenvoudig. Als we de transactie in 
Figuur 9-17 ongedaan willen maken, vervangt de recovery-processor elk gewijzigde 
record door het bijbehorende before image. Als alle before images zijn hersteld, is 
de transactie teruggedraaid. Als we een transactie opnieuw willen uitvoeren, begint 
de recovery-processor met de versie van de database zoals die eruitzag toen de trans- 
actie begon en brengt hij alle after images aan. Hierbij moet een eerdere kopie van 
de database in een database-save aanwezig zijn. 
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Accepteer ordergegevens van browser. 

Lees KLANT- en VERKOPER-records. 

Wijzig KLANT- en VERKOPER-records. 

Schrijf KLANT-record. : 

Schrijf VERKOPER-record. WINseren logrecords 


Voeg nieuwe ORDER-record toe. geschreven) 


“er CRASH**** 


Database met 
nieuwe KLANT-, 
VERKOPER- en 
ORDER-records 


Before images 
van KLANT- en 
VERKOPER-records 


Recoveryprocessor 
(schrijft before images van 
KLANT en VERKOPER en 
verwijdert nieuwe ORDER-record) 


Database waaruit 
ORDER-transactie 
is verwijderd 


(b) 


Figuur9-17 Voorbeeld van een recovery-strategie: (a) verwerking met een probleem en (b) recovery-verwerking 


Om een database terug te brengen naar haar recentste save-toestand en vervolgens 
alle transacties opnieuw toe te passen, kan aardig wat tijd in beslag nemen. Om die 
tijd wat terug te dringen, maken sommige DBMS-producten gebruik van zogeheten 
checkpoints. Een checkpoint is een synchronisatiepunt tussen de database en het 
transactielog. Om een checkpoint uit te voeren, weigert het DBMS nieuwe verzoe- 
ken, rondt het de verwerking van openstaande verzoeken af en schrijft het zijn buf- 
fers naar schijf. Vervolgens wacht het op een bevestiging van het besturingssysteem 
waaruit blijkt dat alle openstaande schrijfverzoeken naar de database en het log suc: 
cesvol zijn afgerond. Het log en de database zijn nu met elkaar gesynchroniseerd. Nu 
wordt er een checkpointrecord naar het log geschreven. De database kan later vanaf 
dit checkpoint worden hersteld. Dan hoeven er alleen after images te worden aange- 
bracht voor transacties die zijn gestart nadat het checkpoint is toegepast. 
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Checkpoints nemen weinig tijd in beslag en kunnen makkelijk drie à vier keer per 
uur (of nog vaker) worden aangebracht. Op die manier hoeft er nooit meer dan vijf: 
tien of twintig minuten werk te worden hersteld. De meeste DBMS-producten plaat- 
sen automatisch checkpoints zonder menselijke tussenkomst. 

In het volgende hoofdstuk maak je kennis met specifieke voorbeelden van back- 
up- en recovery-technieken voor SQL Server. Het is voorlopig voldoende als je weet 
hoe deze technieken globaal in elkaar zitten. Realiseer je dat het de taak is van de 
DBA toe te zien op het opstellen van doelmatige back-up- en recovery-plannen. Ook 
moeten er op de juiste momenten database-saves en logs worden gegenereerd. 


9,6 Het DBMS beheren 


Behalve het beheren van de gegevensactiviteiten en de databasestructuur, moet de 
DBA ook het DBMS zelf beheren. De DBA wordt geacht statistieken over de systeem- 
prestaties bij te houden en te analyseren, en mogelijke probleemgebieden in kaart te 
brengen. Vergeet niet dat de database meestal veel gebruikersgroepen ondersteunt. 
De DBA moet klachten over responstijden, fouten, gebruikersgemak en dergelijke 
onderzoeken en eventueel noodzakelijke aanpassingen plannen en uitvoeren. 

De DBA moet het gebruik van de database constant in de gaten houden. Veel 
DBMS-producten bieden mogelijkheden voor het verzamelen en weergeven van 
statistische gegevens. In dergelijke rapporten kan bijvoorbeeld worden aangegeven 
welke gebruikers actief zijn geweest, welke bestanden en welke gegevens zijn ge- 
raadpleegd en welke toegangsmethoden zijn gebruikt. Ook kunnen foutenpercen- 
tages en fouttypen worden gegenereerd. De DBA analyseert deze gegevens om vast 
te stellen of iets in het databaseontwerp moet worden aangepast wat tot verbetering 
van de prestaties leidt of het gebruikersgemak verhoogt. Als dat het geval is, is het de 
taak van de DBA om te zorgen dat dit gebeurt. 

De DBA moet verder runtime-statistieken over de databaseactiviteit en presta- 
ties analyseren. Als er een probleem in de prestaties wordt vastgesteld (door een 
rapport of een klacht van een gebruiker), moet de DBA bepalen of iets in de databa- 
sestructuur of het databasesysteem moet worden gewijzigd. Voorbeelden van mo- 
gelijke structuurwijzigingen zijn het opstellen van nieuwe sleutels, het wissen van 
gegevens, het verwijderen van sleutels en het invoeren van nieuwe relaties tussen 
objecten. 

Als de leverancier van het gebruikte DBMS een nieuwe versie van het product 
aankondigt, moet de DBA deze beoordelen in het licht van de bestaande gebruikers- 
behoeften. Als de DBA vindt dat de nieuwe functies aan het DBMS moeten worden 
toegevoegd, moeten de gebruikers hiervan op de hoogte worden gesteld en instruc- 
ties krijgen in het gebruik ervan. De DBA moet dus niet alleen wijzigingen in de da- 
tabasestructuur, maar ook wijzigingen in het DBMS zelf beheren en regelen. 

Veel andere taken van de DBA variëren, afhankelijk van het gebruikte DBMS- 
product en de gebruikte hardware en software. Wijzigingen in andere software 
(zoals het besturingssysteem of de webserver) kunnen bijvoorbeeld inhouden dat 
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bepaalde DBMS-functies of parameters moeten worden gewijzigd. De DBA moet het 
DBMS-product dus ook afstellen op het gebruik van andere software. 

Vaak worden bepaalde DBMS-opties (zoals transactie-isolatieniveaus) gekozen 
terwijl nog weinig bekend is over hoe het systeem zich zal gedragen in een bepaalde 
gebruikersomgeving. Daarom kan na enige gebruikerservaring en prestatieanalyse 
blijken dat aanpassingen nodig zijn. Zelfs als de prestaties acceptabel lijken, kan 
worden besloten andere instellingen te gebruiken om te zien wat het effect daarvan 
is. We noemen dit het afstellen, tunen of optimaliseren van het systeem. In Figuur 9-18 
is een overzicht weergegeven van de verantwoordelijkheden van de DBA ten aanzien 
van het DBMS-beheer. 


e Genereren van databaseapplicatie-prestatierapporten. 
e Onderzoeken van klachten van gebruikers over 
systeemprestaties. 
e Beoordelen van de noodzaak van wijzigingen in 
de databasestructuur of applicaties. 


e De databasestructuur aanpassen. 

e Evalueren en implementeren van nieuwe 
DBMS-functies. 

e Tunen van het DBMS. 


Figuur 9-18 Overzicht van verantwoordelijkheden van de DBA ten aanzien van het DBMS-beheer 


9.6.1 De data-repository onderhouden 

Stel je een grote en actieve internetdatabaseapplicatie voor zoals die wordt gebruikt 
door e-commercebedrijven, bijvoorbeeld door een bedrijf dat muziek verkoopt via 
het internet. Bij een dergelijk systeem komen de gegevens mogelijk uit een aantal 
verschillende databases, is er sprake van tientallen verschillende webpagina's en zijn 
er honderden of zelfs duizenden gebruikers. 

Stel nu dat dit bedrijf zijn assortiment wil uitbreiden met de verkoop van sport- 
artikelen. Aan de DBA wordt gevraagd of hij een schatting kan maken van wat er no- 
dig is, hoelang het duurt en wat het kost om de databaseapplicatie overeenkomstig 
aan te passen. 

De DBA moet hiervoor beschikken over metadata over de database, de database- 
applicaties, applicatiecomponenten, de gebruikers en hun rechten en privileges, en 
andere systeemelementen. De database bevat wel wat metadata in haar systeemtabel- 
len, maar deze zijn onvoldoende om een goede schatting te kunnen maken. De DBA 
heeft extra metadata nodig over onder andere COM- en ActiveX-objecten, scriptpro- 
cedures en -functies, ASP-pagina’s, stylesheets en documenttypedefinities. DBMS- 
beveiligingsmechanismen voorzien wel in documentatie over gebruikers, groepen 
en privileges, maar vaak op zo’n manier dat er slecht mee te werken is. 

Daarom ontwikkelen en onderhouden veel organisaties data-repository’s. Dit 
zijn verzamelingen metadata over databases, databaseapplicaties, webpagina's, 
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gebruikers en andere applicatiecomponenten. De repository is soms virtueel, dat wil 
zeggen: opgebouwd uit gegevens van verschillende bronnen, zoals het DBMS, ver- 
siebeheertool, codebibliotheken en hulpmiddelen voor het genereren en bewerken 
van webpagina's. De data-repository kan ook een geïntegreerd product zijn van een 
CASE-leverancier of van andere bedrijven zoals Microsoft of Oracle. 

Hoe dan ook, de DBA moet al lang voordat hem dergelijke vragen worden gesteld 
over het opzetten van zo'n faciliteit hebben nagedacht. De repository moet feitelijk 
worden opgezet terwijl het systeem wordt ontwikkeld en moet als een belangrijk 
onderdeel van het uiteindelijke systeem worden gezien. Als aan de repository onvol- 
doende aandacht wordt besteed, zal de DBA altijd achter de feiten aanlopen door te 
proberen de bestaande applicaties te onderhouden, ze aan nieuwe specificaties aan 
te passen en de metadata op een of andere manier te verzamelen voor een repository. 

De beste repository’s zijn actief — ze maken deel uit van het systeemontwikkel- 
proces zodat automatisch metadata worden gecreëerd als de systeemcomponenten 
worden gecreëerd. Minder wenselijk, maar toch bruikbaar, zijn passieve repository’s, 
die alleen worden gevuld als iemand tijd vindt de benodigde metadata te genereren 
en die in de repository te plaatsen. 


Samenvatting 


In veel organisaties wordt gewerkt met multi-user-databases. Dergelijke databases 
vragen om extra aandacht en daarom is er binnen de organisatie vaak een apart 
team, het databasebeheer, dat dit soort problemen probeert op te lossen. Als wij de 
term databasebeheerder of DBA gebruiken, bedoelen we daarmee de persoon of de 
afdeling die zich bezighoudt met een enkele database. De term databeheerder wordt 
gehanteerd voor het beschrijven van een soortgelijke functie die betrekking heeft op 
alle aspecten binnen een organisatie. In Figuur 9-1 staan de hoofdfuncties van de 
databasebeheerder weergegeven. 

De DBA houdt zich bezig met de ontwikkeling van databasestructuren en zorgt 
voor wijzigingen in de configuratie als daar behoefte aan is. Het bijhouden van een 
goede documentatie van de structuur en de wijzigingen daarin is ook een belangrijke 
taak van de DBA. 

Het doel van concurrency-controlemaatregelen is voorkomen dat het werk van 
de ene gebruiker dat van een andere nadelig beïnvloedt. Er bestaat niet één concur- 
rency-controletechniek die in alle gevallen ideaal is. We moeten afwegingen maken 
tussen de mate van beveiliging en de verwerkingssnelheid van het systeem. Een 
transactie of logical unit of work (LUW) is een reeks bewerkingen die als een atomai- 
re eenheid in de database plaatsvinden — ze vinden dus of allemaal of geen van alle 
plaats. De activiteit van gelijktijdige transacties is vervlochten op de databaseserver. 
Soms gaan wijzigingen verloren als onvoldoende concurrency-controlemaatregelen 
worden genomen. Een ander concurrency-probleem heeft te maken met inconsis- 
tente reads. 

Om concurrency-problemen te voorkomen, worden database-elementen gelockt. 
Impliciete locks worden automatisch door het DBMS geplaatst en expliciete locks 
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worden door de applicatie verstrekt. De omvang van de lock noemen we de lock 
granularity. Door een exclusieve lock wordt andere gebruikers verboden de bron te 
lezen. Bij een shared lock mogen andere gebruikers de bron wel lezen, maar niet 
wijzigen. 

Twee transacties die tegelijkertijd worden uitgevoerd en resultaten genereren die 
in overeenstemming zijn met de resultaten die zouden zijn verkregen als ze apart 
waren uitgevoerd, heten serializable. Tweefaselocking, waarbij locks worden verkre- 
gen in de groeifase en weer worden vrijgegeven in de krimpfase, is een mogelijke op- 
zet voor serializable transacties. Een speciaal geval van tweefaselocking is tijdens de 
transactie locks te plaatsen en pas locks vrij te geven als de transactie achter de rug is. 

Een deadlock treedt op als twee transacties elk wachten op een bron die de andere 
transactie heeft. Een deadlock-situatie is te voorkomen door van transacties te eisen 
dat alle locks in één keer worden geplaatst — als een deadlock optreedt, is die alleen 
te verhelpen door een van de transacties af te breken (en deels voltooid werk terug te 
draaien). Bij optimistische locking wordt ervan uitgegaan dat er geen transactiecon- 
flicten optreden — als dat toch gebeurt, worden maatregelen genomen om die con- 
flicten op te lossen. Bij pessimistische locking wordt aangenomen dat een conflict 

zal plaatsvinden — en voorkomt het conflict door vooraf locks te plaatsen. Bij internet- 
en vele intranetapplicaties kan het best met optimistische locking worden gewerkt. 

De meeste applicaties declareren locks niet expliciet, maar markeren transactie- 
grenzen met transactiestatements als BEGIN, COMMIT en ROLLBACK en decla- 
reren het gewenste gedrag. Het DBMS plaatst vervolgens de juiste locks voor de 
toepassing. 

Een ACID-transactie is een transactie die atomair, consistent, geïsoleerd en duur- 
zaam is. Met duurzaam bedoelen we dat wijzigingen in de database permanent zijn. 
Consistentie kan betrekking hebben op statementniveau of op transactieniveau. Met 
consistentie op transactieniveau bestaat de kans dat een transactie haar eigen wijzi- 
gingen niet ziet. In de SQL-standaard uit 1992 worden vier transactie-isolatieniveaus 
gedefinieerd: read uncommitted, read committed, repeatable read en serializable. De 
kenmerken van deze vier niveaus zijn weergegeven in Figuur 9-10. 

Een cursor is een wijzer die wijst naar een verzameling records. Vier cursortypen 
zijn wijdverbreid: forward only, statisch, keyset en dynamisch. Ontwikkelaars moe- 
ten een isolatieniveau en cursortype selecteren dat zij geschikt achten voor hun toe- 
passing en het gebruikte DBMS-product. 

Met databasebeveiliging probeer je te bereiken dat alleen daarvoor bevoegde per- 
sonen bepaalde activiteiten op daarvoor aangewezen tijdstippen kunnen uitvoeren. 
Hiertoe moeten de verwerkingsrechten en -verantwoordelijkheden van de gebrui- 
kers worden vastgesteld. 

Veel DBMS-producten voorzien in functies voor beveiliging. Bij de meeste hier- 
van kunnen gebruikers, groepen, te beschermen objecten en permissies of privileges 
voor die objecten worden gedeclareerd. Bijna alle DBMS-producten maken gebruik 
van een of andere vorm van beveiliging met gebruikersnamen en wachtwoorden. 
Figuur 9-14 toont richtlijnen voor de beveiliging. De DBMS-beveiliging kan worden 
vergroot door ook de toepassing te beveiligen. 
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Als er een storing is in het systeem, moet de database zo snel mogelijk worden terug- 
gebracht in een bruikbare toestand. Transacties die op het moment van de storing 
werden uitgevoerd, moeten opnieuw worden toegepast of opnieuw worden gestart. 
Soms kan het herstel plaatsvinden via reprocessing, maar het gebruik van logbestan- 
den en rollback en rollforward is bijna altijd een betere oplossing. Het plaatsen van 
checkpoints kan de hoeveelheid werk reduceren die moet worden verricht na een 
storing. 

Het is de taak van de DBA om voor al deze zaken te zorgen. Daarnaast beheert 
de DBA het DBMS-product zelf door regelmatig de prestaties van de databaseappli- 
catie te meten. Hij of zij beoordeelt of wijzigingen in de databasestructuur moeten 
worden aangebracht en of de prestaties van het DBMS kunnen worden verbeterd. 
Verder evalueert en implementeert de DBA nieuwe DBMS-functies en is hij of zij 
verantwoordelijk voor het onderhouden van de data-repository. 


Belangrijke termen 


ACID-transactie 
actieve repository 
after image 
atomair 

before image 
checkpoint 
concurrent update-probleem 
consistent 

cursor 
data-repository 
database save 
databasebeheer 
databasebeheerder 
databeheer 

DBA 

deadlock 

dirty read 
duurzaam 
dynamische cursor 
exclusieve lock 
expliciete lock 
gebruikersgroep 
geïsoleerd 
groeifase 
impliciete lock 
inconsistent read-probleem 
isolatieniveau 
keyset-cursor 


krimpfase 

lock 

lock granularity 

log 

logical unit of work (LUW) 

lost update-probleem 

non-repeatable read 

optimistische locking 

passieve repository 

pessimistische locking 

phantom read 

recovery via reprocessing 

recovery via rollback/rollforward 

resource locking 

rol 

rollback 

rollforward 

scrollable cursor 

serializable 

shared lock 

SQL injection-aanval 

statische cursor 

sterk wachtwoord 

transactie 

tweefaselocking 

verwerkingsrechten en 
-verantwoordelijkheden 
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Oefeningen 


1. 
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Geef een korte beschrijving van vijf problemen die organisaties tegen kunnen 
komen bij het opstellen en gebruiken van multi-user-databases. 

Leg uit wat het verschil is tussen een databasebeheerder en een databeheerder. 
Noem zeven belangrijke taken van een DBA. 
Geef een overzicht van de verantwoordelijkheden van de DBA ten aanzien van 
het beheer van de databasestructuur. 
Wat is configuratiecontrole en waarom is een dergelijke controle belangrijk? 
Leg uit wat wordt bedoeld met het woord nadelig in de zin: ‘Het werk van de ene 
gebruiker beïnvloedt het werk van een andere nadelig.” 
Welke afwegingen moeten worden gemaakt bij concurrency-controle? 

Geef de definitie van een atomaire transactie en leg uit waarom atomair van be- 
lang is. 

Wat is het verschil tussen gelijktijdige (concurrent) transacties en parallelle 
(simultaneous) transacties? Hoeveel CPU's zijn nodig voor parallelle transacties? 
Bedenk zelf een voorbeeld van het lost update-probleem. 

Wat is het verschil tussen expliciete en impliciete locks? 

Wat bedoelen we met lock granularity? 

Leg uit wat het verschil is tussen exclusieve locks en shared locks. 

Leg uit hoe tweefaselocking in zijn werk gaat. 


Op welke wijze staat de vrijgave van alle locks aan het eind van een transactie in 
verband met tweefaselocking? 


„ Geef in algemene bewoordingen aan hoe de grenzen van een transactie moeten 


worden gedefinieerd. 


Wat is een deadlock? Hoe is een deadlock te voorkomen? Hoe is een deadlock te 
doorbreken? 

Wat is het verschil tussen optimistische en pessimistische locking? 

Wat zijn de voordelen van het markeren van transactiegrenzen, het declareren 
van lock-kenmerken en het door het DBMS laten plaatsen van locks? Leg uit 


waarvoor de statements BEGIN, COMMIT en ROLLBACK TRANSACTION 
worden gebruikt. 


. Wat is een ACID-transactie? 


Geef een beschrijving van consistentie op statementniveau. 


„ Geef een beschrijving van consistentie op transactieniveau. Welk nadeel kan aan 


deze vorm van consistentie zijn verbonden? 
Wat is het doel van transactie-isolatieniveaus? 


. Leg uit wat we bedoelen met het read uncommitted-isolatieniveau en geef een 


toepassingsvoorbeeld. 


Leg uit wat we bedoelen met het read committed-isolatieniveau en geef een 
toepassingsvoorbeeld. 


. Leg uit wat we bedoelen met het repeatable read-isolatieniveau en geef een 


toepassingsvoorbeeld. 
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Leg uit wat we bedoelen met het serializable isolatieniveau en geef een 
toepassingsvoorbeeld. 


. Wat is een cursor in dit verband? 


Leg uit waarom een transactie verscheidene cursors kan hebben. Hoe is het 


mogelijk dat een transactie meer dan één cursor voor een bepaalde tabel kan 
hebben? 


„ Wat is het voordeel van het gebruik van verschillende cursortypen? 


Leg uit wat we bedoelen met forward only-cursors en geef een toepassings- 
voorbeeld. 

Leg uit wat we bedoelen met statische cursors en geef een toepassingsvoorbeeld. 
Leg uit wat we bedoelen met keyset-cursors en geef een toepassingsvoorbeeld. 
Leguitwatwebedoelenmetdynamischecursorsen geefeentoepassingsvoorbeeld. 
Wat gebeurt er als er geen transactie-isolatieniveau en cursortype voor het 
DBMS worden gedeclareerd? Is dat voor- of nadelig? 

Leg uit waarom het noodzakelijk is verwerkingsrechten en -verantwoordelijk- 
heden te definiëren. Hoe worden zulke verantwoordelijkheden opgelegd? 
Verklaar de relaties tussen USER, GROEP, PERMISSION en OBJECTEN voor 
een generiek databasebeveiligingssysteem. 

Mag de DBA tijdens het plannen van de beveiliging aannemen dat er een fire- 
wall wordt gebruikt? 


. Wat moet er gedaan worden met ongebruikte mogelijkheden en functies van het 


DBMS-product? 


. Leg uit hoe de computer die het DBMS uitvoert beveiligd moet worden. 


Welke acties moet de DBA ondernemen met betrekking tot de beveiliging wat 
betreft gebruikersaccounts en wachtwoorden? 

Noem twee elementen van een plan voor de databasebeveiliging. 

Beschrijf de voor- en nadelen van door het DBMS geleverde en door de toepas- 
sing geleverde beveiliging. 


. Wat is een SQL injection-aanval en hoe kan deze worden voorkomen? 


Leg uit hoe een database kan worden hersteld door het opnieuw uitvoeren van 
bewerkingen (reprocessing). Waarom is reprocessing meestal geen geschikte 
oplossing? 


. Wat is rollback en wat is rollforward? 
„ Waarom is het belangrijk databasewijzigingen te loggen voordat ze op de data- 


base worden toegepast? 


„ Beschrijf het rollback-proces en geef aan onder welke omstandigheden dit moet 


worden gebruikt. 


. Beschrijf het rollforward-proces. Onder welke omstandigheden moet dit proces 


worden gebruikt? 


Waarom is het zinvol regelmatig controlepunten (checkpoints) in het logbe- 
stand op te nemen? 


Geef een overzicht van de verantwoordelijkheden van de DBA ten aanzien van 
het beheer van het DBMS. 
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52. 


53: 


Wat is een data-repository? Wat is een passieve data-repository? Wat is een ac- 
tieve data-repository? 

Waarom is een data-repository belangrijk? Wat kan er gebeuren als er geen data- 
repository beschikbaar is? 


Projectvragen 


54. 


55: 


56. 


57: 


Ga naar www.msdn.microsoft.com en zoek naar SQL Server Security Guidelines. 
Volg drie van de links die je hier vindt, lees de artikelen en vat ze samen. Verge- 
lijk de informatie die je hebt gevonden met die in Figuur 9-14. 

Ga naar www.oracle.com en zoek naar Oracle Security Guidelines. Volg drie van 
de links die je hier vindt, lees de artikelen en vat ze samen. Vergelijk de infor- 

matie die je hebt gevonden met die in Figuur g-14. 

Ga naar www.mysql.com en zoek naar Security Guidelines. Volg drie van de links 

die je hier vindt, lees de artikelen en vat ze samen. Vergelijk de informatie die je 

hebt gevonden met die in Figuur 9-13. 

Beantwoord de volgende vragen over de in hoofdstuk 7 besproken View Ridge- 

database aan de hand van de in Figuur 7-13 getoonde tabellen. 

A. Stel dat je een opgeslagen procedure moet ontwikkelen voor het registreren 
van een kunstenaar van wie nog nooit eerder werk in de galerie is getoond, 
samen met een werk van die kunstenaar en een rij in de TRANS-tabel voor 
het registreren van de aankoopdatum en de aankoopprijs. Hoe declareer je 
de grenzen van de transactie? Welk transactie-isolatieniveau gebruik je? 

B. Stel dat je een opgeslagen procedure moet schrijven voor het wijzigen van 
waarden in de tabel KLANT. Welk transactie-isolatieniveau gebruik je? 

C. Stel dat je een opgeslagen procedure moet schrijven voor het registreren 
van de aankopen van een klant. Neem aan dat de klantgegevens nieuw zijn. 
Hoe declareer je de grenzen van de transactie? Welk isolatieniveau gebruik 
je? 

D. Stel dat je een opgeslagen procedure aan het schrijven bent die de geldig- 
heid moet controleren van de intersectietabel. Je procedure moet specifiek 
transacties van klanten lezen en bepalen welke kunstenaar het werk heeft 
gemaakt. Je procedure moet dan, als de kunstenaar bekend is, controleren 
of er een interesse in die kunstenaar is opgegeven in de intersectietabel. Is 
er geen intersectierij, dan moet jouw procedure er een maken. Hoe stel je 
de grenzen van jouw transactie in? Welk isolatieniveau gebruik je? Welke 
cursortypen gebruik je (als je die gebruikt)? 


Marcia’s Chemische Reiniging 


À. 
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Neem aan dat Marcia je heeft ingehuurd als een databaseconsultant, om een 
operationele database te ontwikkelen met de volgende vier tabellen (dat zijn de- 
zelfde tabellen als aan het eind van hoofdstuk 7 beschreven): 
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CUSTOMER (CustomerlD, FirstName, LastName, Phone, E-mail) 
INVOICE (InvoiceNumbder, CustomerID, Dateln, DateOut, Subtotal, 
Tax, TotalAmount) 

INVOICE ITEM (ZnvoiceNumber, ItemNumber, Service, Quantity, 
UnitPrice, ExtendedPrice) 

SERVICE (Service, Description, UnitPrice) 


Neem aan dat Marcia het volgende personeel heeft: twee eigenaars, een ploeg- 
manager, een parttime naaister en twee winkelbediendes. Bereid een memo van 
twee tot drie pagina’s voor dat de volgende punten aanspreekt: 

1. De noodzaak tot databasebeheer. 

2. Jouw aanbeveling over wie de rol van databasebeheerder op zich moet ne- 
men. Ga ervan uit dat Marcia niet zo groot is dat voor die taak een fulltime 
databasebeheerder moet worden aangenomen. 

3. Beschrijf aan de hand van Figuur g-1 de aard van de activiteiten van de data- 
basebeheerder bij Marcia. Je mag natuurlijk ook jezelf aanbevelen om be- 
paalde DBA-functies uit te voeren. 

Definieer gebruikers, groepen en permissies voor de gegevens in de vier tabel- 
len voor de werknemers die in vraag A zijn beschreven. Gebruik het beveili- 
gingsschema uit Figuur 9-13 als voorbeeld en maak een tabel zoals die in Figuur 
9-12. Vergeet niet jezelf daarin op te nemen. 
Stel dat je een opgeslagen procedure aan het schrijven bent voor het maken van 
nieuwe records in SERVICE voor nieuwe diensten die Marcia zal leveren. Stel 
dat je weet dat er tijdens het uitvoeren van jouw procedure een andere opgesla- 
gen procedure kan worden uitgevoerd, die nieuwe records kan opslaan of be- 
staande klantengegevens en registraties kan wijzigen. Stel nu dat er bovendien 
ook nog een derde opgeslagen procedure uitgevoerd kan worden, die nieuwe 
klantgegevens registreert. 

L._ Geef een voorbeeld van een dirty read, een non-repeatable read en een 
phantom read met deze groep opgeslagen procedures. 

2. Welke concurrency-controlemaatregelen moeten er volgens jou genomen 
worden voor de opgeslagen procedure die je aan het maken bent? 

3. Welke concurrency-controlemaatregelen moeten er volgens jou genomen 
worden voor de andere twee opgeslagen procedures? 


Importbedrijf Morgan 


À. 


Neem aan dat Morgan je heeft ingehuurd als een databaseconsultant, om een 
operationele database te ontwikkelen met de volgende vijf tabellen (dat zijn de- 
zelfde tabellen als aan het eind van hoofdstuk 7 beschreven): 


STORE (StoreID, StoreName, City, Country, Phone, Fax, E-mail, 
Contact) 
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PURCHASE 

(PurchaselD, StorelID, Date, Description, Category, PriceUSD) 
SHIPMENT 

(ShipmentID, ShipDate, ShipperName, ShipperInvoiceNumber, 
Origin, Destination) 

SHIPMENT _ITEM (ShipmentID, PurchaselD, InsuredValue) 
SHIPPER (ShipperName, Phone, Fax, E-mail, Contact) 


Stel dat het personeel van Morgan bestaat uit de eigenaar (Morgan), een ad- 

ministratief medewerker, een fulltime verkoper en twee parttime verkopers. 

Morgan en de administratief medewerker willen gegevens in alle tabellen ver- 

werken. De fulltime verkoper voert bovendien gegevens in over verkopen en le- 

veringen. De parttime werknemers kunnen de leveringsgegevens alleen lezen — 
ze mogen de InsuredValue echter niet zien. 

Stel een memo op van drie tot vijf pagina’s voor de eigenaar van Morgan waarin 

de volgende zaken aan bod komen: 

1. _ De noodzaak voor een databasebeheer bij Morgan. 

2. Jouw aanbeveling over wie de rol van databasebeheerder op zich moet ne- 
men. Ga ervan uit dat Morgan niet zo groot is dat voor die taak een fulltime 
databasebeheerder moet worden aangenomen. 

3. Beschrijf aan de hand van Figuur 9-1 de aard van de activiteiten van de data- 
basebeheerder bij Morgan. Je mag natuurlijk ook jezelf aanbevelen om be- 
paalde DBA-functies uit te voeren. 

Definieer gebruikers, groepen en permissies voor de gegevens in de vijf tabellen 

voor de werknemers die in vraag A zijn beschreven. Gebruik het beveiligings- 

schema uit Figuur 9-13 als voorbeeld en maak een tabel zoals die in Figuur 9-12. 

Vergeet niet jezelf daarin op te nemen. 

Stel dat je een opgeslagen procedure aan het schrijven bent voor het opslaan van 

nieuwe aankopen. Stel dat je weet dat er tijdens het uitvoeren van jouw proce- 

dure een andere opgeslagen procedure kan worden uitgevoerd die services re- 
gistreert, evenals een derde procedure die leveringen registreert. 

1. Geef een voorbeeld van een dirty read, een non-repeatable read en een 
phantom read met deze groep opgeslagen procedures. 

2. Welke concurrency-controlemaatregelen moeten er volgens jou genomen 
worden voor de opgeslagen procedure die je aan het maken bent? 

3. Welke concurrency-controlemaatregelen moeten er volgens jou genomen 
worden voor de andere twee opgeslagen procedures? 


Hoofdstuk 10 
Databases beheren met SQL 
Server 2008 


In dit hoofdstuk komen de belangrijkste functies en mogelijkheden van Microsoft SQL 
Server 2008 aan bod. We maken daarbij gebruik van het voorbeeld View Ridge Galerie 
uit hoofdstuk 7. De bespreking verloopt op dezelfde wijze als die van de databasebe- 
heertaken uit hoofdstuk 9. 

SQL Server is een uitgebreid en ingewikkeld product. In dit ene hoofdstuk kunnen 
we slechts een tipje van de sluier oplichten. Het doel is om SQL Server voor je eigen 
projecten te kunnen gebruiken en voldoende kennis te vergaren waarmee je verder 
zelf aan de slag kunt gaan of die als basis kan dienen voor eventuele vervolgcursussen. 
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10.1 SQL Server 2008 installeren 


Microsoft SQL Server is beschikbaar in veel verschillende versies, op de website www. 
microsoft.com/sqlserver/2008/en/us/editions.aspx vind je daar informatie over. 

De Enterprise-editie is het meest krachtig en heeft de meeste voorzieningen, 
waaronder mogelijkheden voor datawarehousing. De Standard-editie is een eenvou- 
diger versie. 

De Express-editie heeft de minste mogelijkheden, maar is een uitstekend DBMS 
voor studiedoeleinden en is gratis. 

SQL Server 2008 Express kent ook weer verschillende edities: alleen de database- 
engine, de engine met managementtools in de vorm van SQL Server Management 
Studio Express, en de engine met tools en rapportmogelijkheden. Deze laatste versie 
heet SQL Server 2008 with Advanced Services. Deze zullen we in dit boek gebruiken. 

Voordat je SQL Server downloadt, moet je in elk geval eerst de beschikking heb- 
ben over de volgende software: 

1. Microsoft .NET Framework version 3.5 Service Pack 1 
2. Microsoft Windows Installer 4.5 
3. Microsoft Windows PowerShell r.o 


Zonder deze software is het niet mogelijk SQL Server te installeren. Tot besluit in- 
stalleer je: 


4. Microsoft SQL Server 2008 Express with Advanced Services 


Startpunt voor het downloaden van SQL Server 2008 Express is www.microsoft. 
com/sqlserver/2008/en/us/express.aspx. 

Hoewel SQL Server 2008 Express Advanced geschikt is voor de meeste onder- 
werpen in dit boek, is het niet geschikt voor de business intelligence(BI)-systemen, 
die in hoofdstuk 13 ter sprake komen. Daar heb je de Enterprise-editie voor nodig. Je 
kunt een 180 dagen-probeerversie van deze editie downloaden van www.microsoft. 
com/sqiserver/2008/en/us/trial-software.aspx. 

Ongeacht welke versie van SQL Server 2008 je wilt gaan gebruiken, het is in elk 
geval verstandig deze nu te installeren. Controleer ook of er nog patches en service 
packs zijn zodat de installatie zo betrouwbaar mogelijk is. 


10.2 Microsoft SQL Server Management Studio 


Na het installeren van SQL Server 2008 kun je met dit programma beginnen te wer- 
ken door Microsoft SQL Server Management Studio te openen. Er verschijnt dan de 
dialoogbox Connect to Server, zoals in Figuur 1o-1. 

Nadat je op Connect hebt geklikt, verschijnt aan de linkerkant in de zogeheten 
Object Explorer de map Databases. Door deze map te openen, kun je zien welke 
databases op dit moment aanwezig zijn. 
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Kies Windows 


UE xl 
Marot 
ed SQL Server 2008 
EE 


Klik op Connect 


Figuur 10-1 De dialoogbox Connect tot Server 


10.3 Een SQL Server 2008-database maken 


We gaan een nieuwe database maken met de naam VRG voor de database van gale- 
rie View Ridge uit hoofdstuk 6, waarvoor in hoofdstuk 7 een groot aantal SQL state- 
ments staat. 


Een SQL Server 2008 database maken 

1. Klik rechts op de map Databases in de Object Explorer. 

2. Klik in het snelmenu dat verschijnt op New Database. 

3. Typ als naam voor de database de naam VRG in en klik op OK. 


De database met de naam VRG wordt gemaakt en het databaseobject wordt getoond 
in de Object Explorer. 
4. Klik rechts op het VRG-databaseobject en kies Properties in het menu. 


Er verschijnt een venster Database Properties, zoals in Figuur 10-2. 


5. Klik linksboven in dit venster op het Files-pageobject, zoals in Figuur 1o-2, om de 
files te tonen die bij de VRG-database horen. 
6. Klik op OK om het venster te sluiten. 


10.3.1 Een script bewaren 

Tabellen (en de meeste andere SQL Server 2008-structuren) zijn op twee manieren 
te creëren en te wijzigen. De eerste manier is door SQL-code te schrijven met be- 
hulp van het SQL-statement CREATE of het statement ALTER. De tweede manier 
is de grafische mogelijkheden van SQL Server Enterprise Manager te gebruiken. 


373 


DEEL 4 | MULTI-USER-OAABASEVERWERKING 


Me U ten Tan Vree Cms, vb 


„tenQen jh A A 


Het venster Database 
Properties met Files 
geselecteerd 


tente 


Figuur 10-2 Het dialoogvenster Database Properties 


CREATE-statements werken makkelijker, om redenen die we in hoofdstuk 7 hebben 
genoemd. Sommige vakmensen kiezen ervoor structuren te maken via SQL, maar 
ze te wijzigen met de grafische tools. 

We zullen hier SQL-code schrijven met behulp van de SQL Statement Editor. Dit 
is een teksteditor waarin je SQL-statements (een script) kunt invoeren, wijzigen en 
opslaan als tekstbestand, zodat je ze later opnieuw kunt gebruiken. 


Open een SQL Server 2008 SQL Statement Editor Window 
1. Klik op het VRG Database-object in de Object Browser. 
2. Klik op de New Query-knop (zie Figuur 10-3). 


De SQL Editor wordt geopend, zoals in Figuur 10-3. 


3. Klik op de Intellisense-knop om Intellisense uit te zetten (zie Figuur 10-3). In- 
tellisense is een contextgevoelige helpfunctie die nuttig is voor ervaren ontwik- 
kelaars, maar die nogal verwarrend kan zijn als je niet weet hoe je haar moet 
gebruiken. 

4. Typ nu de volgende tekst in de editor: 


/* SQL-script voor het maken ij 
(LS van de tabelstructuur voor VRG */ 


5. Klik op de Save-knop (of kies File | Save). 
6. Klik in het dialoogvenster dat verschijnt op de knop voor het maken van een nieu- 


we map (New Folder). 
7. Geef de map als naam View-Ridge-Gallery-Database. 
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Figuur 10-3 Oe SQL-editor 


8. Klik op OK. 
9. Typ als filenaam VRG-Create-Tables. 
io. Klik op de Save-knop. 


Het script wordt bewaard. 
u. Klik op het kruisje in de rechterbovenhoek van het document om het venster met 
het script te sluiten. 


10.3.2 De tabellen voor de View Ridge-database maken 
De SQL-code voor het maken van de tabellen voor de View Ridge-database is in 
hoofdstuk 7 beschreven en staat in Figuur 7-11. 

Je kunt deze code zelf intikken of downloaden van de website bij dit boek, www. 
pearsoneducation.nl/kroenke. 


De tabelstructuur voor VRG maken met SQL Statements 

1. Klik in SQL Server Management Studio op de Open File-knop (of kies File | 
Open). 

2. Open het bestand VRG-Create-Tables.sql dat je in de vorige paragraaf hebt 
gemaakt. 

3. Klik op de Intellisense Enabled-knop om deze functie uit te zetten. 

4. Typ de SQL-statements uit Figuur 7-11. In plaats van typen kun je het script down- 
loaden (zie boven), openen in een editor als Kladblok of Word, en de volledige 
tekst kopiëren en plakken in het venster van SQL Editor. 

5. Bewaar het script. In de kantlijn laat een groene lijn zien dat het script bewaard 
is. 

6. Scrol naar de bovenkant van het script. Het venster ziet eruit als in Figuur IO-4. 
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Figuur 10-4 Het SQL-script om de VRG-tabelstructuur te maken 


7. Selecteer de database met de naam VRG in de Object Explorer aan de linkerkant. 
8. Klik op de Parse-knop die je in Figuur ro-4 ziet. 


Er verschijnt een venster met een mededeling. Als de mededeling luidt: ‘The 

command(s) completed successfully’ dan staan er waarschijnlijk geen fouten in het 

script. Als er wel fouten zijn, moet je die eerst verbeteren. Herhaal deze stap tot je de 

boodschap ‘The command(s) completed successfully’ ziet. 

g. Klik op Save om het script te bewaren. 

to. Klik op de Execute-knop (zie Figuur 10-4). De tabellen worden gemaakt en de me- 
dedeling ‘The command(s) completed successfully’ verschijnt. 

mm. Open in de Object Explorer de map VRG Tables om de tabellen te zien. 

12. Sluit het SQL-script. 


Je hebt nu de tabellen en relaties voor VRG gemaakt. De afkorting dbo die je voor 
de namen van de tabellen ziet, staat voor database owner. Dat ben je zelf als je SQL 
Server hebt geïnstalleerd en deze database hebt gemaakt. 


10.3.3 De structuur van de tabellen bekijken 

Nu de tabellen gemaakt zijn, kunnen we hun structuur bekijken. Laten we kijken 
naar de tabel ARTIST en in het bijzonder naar de eigenschappen van de primaire 
sleutel ArtistID. 


De structuur van de tabel ARTIST bekijken 

ra. Klik rechts op het tabelobject dbo.ARTIST in de Object Browser van SQL Server 
Management Studio. 

13. Klik in het snelmenu op Design. 
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Het ontwerp van de tabel ARTIST wordt getoond in een venster als in Figuur 10-5. 


„il 


| De kolommen van 
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| De eigenschappen | P 
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| De eigenschappen 
van de Identity Is 
\ Specification 


Figuur 10-5 De kolommen van de tabel ARTIST en hun eigenschappen 


14. Klik op het kruisje om dit venster te sluiten. 


10.3.4 De constraints bekijken 
Je kunt ook de constraints bekijken die voor de tabel ARTIST zijn gedefinieerd. In 
de SQL-code waarmee de tabel is gemaakt (Figuur 7-11) staat onder andere een con- 
straint met de naam ValidBirthYear. 


De constraints van de tabel ARTIST bekijken 

1. Klik (indien nodig) in de Object Browser van SQL Server Management Studio op 
dbo.ARTIST om de folder open te klappen. 

2. Klap de Constraints-folder open. 


The constraints van de tabel ARTIST worden getoond in de Object Browser. 
3. Klik rechts op ValidBirthYear en kies Modify in het snelmenu. 


Het dialoogvenster Check Constraints verschijnt. 

Merk op dat de check-constraint in het tekstvak bij Expression staat, zo nodig kun je 

hem hier wijzigen, maar dat zullen we nu niet doen. 

4. Sluit het dialoogvenster met de Close-knop en sluit het venster met de 
kolomeigenschappen. 

5. Klap het object dbo. ARTIST in. 
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10.3.5 Een databasediagram maken 


Om ons ervan te verzekeren dat de relaties in de VRG-database correct zijn, kunnen 
we een diagram van deze database maken. 


Een databasediagram maken 


1. Klik in de Object Browser van SQL Server Management Studio rechts op de fol- 
der VRG Database Diagrams. 


2. Kies Install Diagram Support in het snelmenu. 


3. Klik Yes als antwoord op de vraag of je de objecten voor de diagrammen wilt 
maken. 


4. Klik rechts op de folder VRG Database Diagrams. 
5. Kies New Database Diagram in het snelmenu. 


Het dialoogvenster Add Table verschijnt. 

6. Klik op de knop Add om de tabel ARTIST aan het diagram toe te voegen. 
7. Klik één voor één op de vier andere tabellen en voeg die ook toe. 

8. Sluit het dialoogvenster. 


g. Verplaats de tabellen in het diagram zodat je een diagram krijgt dat lijkt op dat in 


Figuur 10-6. 
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Figuur 10-6 Het VRG-databasediagram 


ro. Klik op de Save-knop en geef het diagram de naam VRG-Database-Diagram. 
We kunnen dit diagram gebruiken om de eigenschappen van relaties te bekijken. Bij- 


voorbeeld de relatie tussen ARTIST en WORK, de referentiële-integriteit-constraint 
en het cascading update en -deletion gedrag tussen ARTIST en WORK. 
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10.3.6 Eigenschappen van een relatie bekijken 
Via het databasediagram uit de vorige paragraaf kun je de eigenschappen van de 
relatie tussen bijvoorbeeld ARTIST en WORK bekijken. 


Eigenschappen van een relatie bekijken 
1. Klik rechts op de tabel ARTIST in het VRG Database Diagram. 
2. Kies Relationships in het snelmenu. 


Het dialoogvenster Foreign Key Relationship verschijnt. 
3. Klap de sectie Tables and Columns Specifications uit. 


Merk op dat de eigenschap Check Existing Data On Creation Or Re-Enabling is 
aangevinkt. 

Dit is de referential integrity constraint tussen ArtistID in WORK en ArtistID in 
ARTIST. 


4. Klap in het dialoogvenster Foreign Key Relationships INSERT and UPDATE 
Specification uit en scrol naar beneden totdat de eigenschappen zichtbaar worden. 


De eigenschappen geven aan dat noch updates van de primaire sleutel van ARTIST, 
noch verwijderingen van rijen in ARTIST aanleiding geven voor cascading actions 
in de tabel WORK. 


5. Klik op Close om het dialoogvenster Foreign Key Relationships te sluiten. 
6. Klik op Close om het venster VRG Database Diagram te sluiten. 


10.3.7 Gegevens invoeren in de tabellen 
Je kunt gegevens in SQL Server Management Studio invoeren via een tabelraster of 
via SQL INSERT-statements. Het tabelraster voor de invoer krijg je door rechts te 
klikken op de tabelnaam en uit het snelmenu Edit Top 200 Rows te kiezen. 

Wij zullen echter de invoer doen op de manier waarop we de tabellen gemaakt 
hebben: met behulp van een script. 

Je kunt het script met de naam VRG-Table-Data.sql downloaden van de website 
bij dit boek: www.pearsoneducation.nl/kroenke. 


1. Klik op het VRG Database-object in de Object Browser. 

2. Klik op de New Query-knop (zie Figuur 10-3). 

3. Klik eventueel op de Intellisense Enabled-knop (Figuur 10-3) om deze functie uit 
te zetten. 

4. Download het script VRG-Table-Data.sql en open het in een editor als Kladblok of 
Word; kopieer de volledige tekst en plak deze in het venster van SQL Editor. 

5. Bewaar het script en geef het als naam VRG-Table-Data. 

6. Scrol naar de bovenkant van het script. Het venster ziet eruit als in Figuur 10-4. 
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7. Zorg dat de database met de naam VRG in de Object Explorer is geselecteerd. 

8. Test het script door op de Parse-knop te klikken (Figuur 10-4). 

9. Zorg dat er geen fouten in het script staan, bewaar het en klik op de Execute-knop 
(Figuur 10-4) om het script te laten uitvoeren. 

to. Sluit na het runnen het venster met het script. 


10.3.8 Een view maken 
Views bespraken we in hoofdstuk 7. Een van de views die we maakten, was Customer- 
InterestsView (paragraaf 7.7.3). In SQL Server 2008 kun je views maken door mid- 
del van een script of met behulp van de grafische interface door rechts te klikken op 
de folder Views en in het snelmenu New View te kiezen. 

CustomerlInterestsView maak je met het volgende SQL-statement: 


CREATE VIEW CustomerInterestsView AS 
SELECT C.LastName AS CustomerLastName, 
C.FirstName AS CustomerFirstName, 
A.LastName AS ArtistName 
FROM CUSTOMER AS C JOIN CUSTOMER ARTIST INT ASCI 
ON C.CustomerID = CI.CustomerID 
JOIN ARTIST AS A 
ON CI.ArtistID = A.ArtistID; 


td AO] 


De Execute-knop 


1 De 
î 
2 if 
ad 
vi 
Nt 
ck 
*Î 

: 


De Parse-knop oss we: 


De Intellisense 
Enabled-knop 


De folder Views 


Het object 
dbo.CustomerlinterestsView 


MEENDEN WTA (HO AG DD Drees 


Med na ct re an hd 


Figuur 10-7 Een SQl-view maken 


In Figuur 1o-7 zie je deze CREATE VIEW-opdracht in een script in SQL Server 
Management Studio. Je kunt dit script als volgt maken en testen. 
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Een nieuwe view maken 

1. Klik in de Object Explorer op New Query. 

2. Klik op de Intellisense Enabled-knop om Intellisense uit te zetten. 

3. Typ het SQL-statement voor CustomerInterestsView zoals dat hierboven staat 
afgedrukt. 

. Klik op de Parse-knop. Als er fouten zijn, verbeter ze dan. 

5. Klik op Execute. 

6. Open de folder Views in het VRG-databaseobject. Merk op dat het object dbo. 
CustomerlInterestsView is toegevoegd, zie Figuur 10-7. 

7. Bewaar het script als VRG-Create-Views.sql. 

8. Sluit het venster van het script. 


We kunnen nu de grafische weergave van deze view bekijken. 


De grafische weergave 
van de view 
dbo.CustomerinterestsView 


Ge 
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raa 


Figuur 10-8 Grafische weergave van een view 


De grafische weergave van een bestaande view bekijken 
1. Klik rechts op het object dbo.CustomerlInterestsView. 
2. Klik in het snelmenu op Design. 


De grafische weergave van dbo.CustomerInterestsView wordt nu getoond in een 
venster. 


3. Rangschik de onderdelen zodanig dat de weergave eruitziet als in Figuur 10-8. 


4. Klik op de Save-knop om de weergave te bewaren. 
5. Sluit het venster van de weergave. 
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7. Zorg dat de database met de naam VRG in de Object Explorer is geselecteerd. 

8. Test het script door op de Parse-knop te klikken (Figuur 10-4). 

9. Zorg dat er geen fouten in het script staan, bewaar het en klik op de Execute-knop 
(Figuur 10-4) om het script te laten uitvoeren. 

ro. Sluit na het runnen het venster met het script. 


10.3.8 Een view maken 
Views bespraken we in hoofdstuk 7. Een van de views die we maakten, was Customer- 
InterestsView (paragraaf 7.7.3). In SQL Server 2008 kun je views maken door mid- 
del van een script of met behulp van de grafische interface door rechts te klikken op 
de folder Views en in het snelmenu New View te kiezen. 

CustomerlInterestsView maak je met het volgende SQL-statement: 


CREATE VIEW CustomerInterestsView AS 
SELECT C.LastName AS CustomerlLastName, 
C.FirstName AS CustomerFirstName, 
A.LastName AS ArtistName 
FROM CUSTOMER AS C JOIN CUSTOMER ARTIST _INT ASCI 
ON C.CustomerID = CI.CustomerID 
JOIN ARTIST AS A 
ON CI.ArtistID = A.ArtistID; 
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Figuur 10-7 Een SQL-view maken 


In Figuur 10-7 zie je deze CREATE VIEW-opdracht in een script in SQL Server 
Management Studio. Je kunt dit script als volgt maken en testen. 
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Een nieuwe view maken 
1. Klik in de Object Explorer op New Query. 
2. Klik op de Intellisense Enabled-knop om Intellisense uit te zetten. 
3. Typ het SQL-statement voor CustomerlInterestsView zoals dat hierboven staat 
afgedrukt. 
. Klik op de Parse-knop. Als er fouten zijn, verbeter ze dan. 
5. Klik op Execute. 
6. Open de folder Views in het VRG-databaseobject. Merk op dat het object dbo. 
CustomerlnterestsView is toegevoegd, zie Figuur 10-7. 
Bewaar het script als VRG-Create-Views.sql. 
Sluit het venster van het script. 


po 


We kunnen nu de grafische weergave van deze view bekijken. 
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Figuur 10-8 Grafische weergave van een view 


De grafische weergave van een bestaande view bekijken 
L. Klik rechts op het object dbo.CustomerInterestsView. 
2. Klik in het snelmenu op Design. 


De grafische weergave van dbo.CustomerlnterestsView wordt nu getoond in een 
venster. 


3. Rangschik de onderdelen zodanig dat de weergave eruitziet als in Figuur 10-8. 


4. Klik op de Save-knop om de weergave te bewaren. 
5. Sluit het venster van de weergave. 
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Zoals in hoofdstuk 7 is uitgelegd, gebruik je views in SQL net als tabellen. Om 
bijvoorbeeld alle gegevens van de view te zien, gebruik je het volgende SQL 
SELECT-statement: 


SELECT * 
FROM CustomerInterestsView 


ORDER BY CustomerLastName, CustomerFirstName; 


Het resultaat zie je in Figuur 10-9. 


|___| CustomerlastName | CustomerfirstName | AtistName 

2 Frederickson Mary Beth Kandinsky 
3 Frederickson Mary Beth Miro 

4 Frederickson Mary Beth Matisse 

5 Gray Donald Tobey 

6 Gray Donald Horiuchi 

7 Gray Donald Graves 

8 Janes Jeffrey Graves 

9 Janes Jeffrey Horiuchi 
10 | Janes Jeffrey Tobey 

11_| Smathers Fred Tobey 

12 | Smathers Fred Horiuchi 
13 | Smathers Fred Graves 

14 | Smith David Chagall 


Matisse 


figuur 10-9 Het resultaat van CustomerinterestsView 
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10.4 Applicatielogica 


Een SQL Server-database kan op tal van manieren worden verwerkt. Met de eerste 
manier zijn we al vertrouwd: door middel van SQL-scripts. Om veiligheidsredenen 
worden dergelijke bestanden alleen gebruikt in de ontwikkel- en testfase, maar nooit 
op een operationele database. 

Een andere manier is het maken van applicatiecode met een Microsoft .NET-taal 
zoals C#.NET, C++.NET, VB.NET of met een andere programmeertaal om vanuit 
zo'n programma SQL Server-DBMS-commando'’s aan te roepen. De moderne ma- 
nier daarvoor bestaat eruit een bibliotheek van objectklassen te gebruiken en objec- 
ten te maken die het databasewerk verrichten. 

Je kunt applicatielogica ook in triggers opnemen. Triggers kunnen, zoals je al in 
hoofdstuk 7 leerde, worden gebruikt voor validatiecontrole, voor het instellen van de- 
faultwaarden, voor het bijwerken van views en voor het implementeren van referen- 
tial integrity acties. We beschrijven in dit hoofdstuk vier triggers — een voor elk van 
de vier gebruiksdoelen voor triggers. Deze triggers zullen worden aangeroepen door 
SQL Server als de opgegeven acties optreden. 

Een SQL Server-database kan ook worden verwerkt door opgeslagen procedures 
te maken zoals we in hoofdstuk 7 beschreven. Deze procedures kunnen dan wor- 
den aangeroepen vanuit applicaties of webpagina's via talen zoals VBScript of PHP. 
Opgeslagen procedures kunnen ook worden uitgevoerd vanuit de SQL Server Ma- 
nagement Studio. Dat moet echter alleen gedaan worden tijdens het ontwikkelen 
en testen van de procedures. Zoals we al in hoofdstuk 9 beschreven, is het vanwege 
beveiligingsredenen niemand buiten de geautoriseerde DBA-personeelsleden toe- 
gestaan interactief met een database te weWe lichten in dit hoofdstuk een opgesla- 
gen procedure toe. We testen deze procedure door hem aan te roepen vanuit SQL 
Server Management Studio. Dat mag ook weer alleen tijdens het ontwikkelen en 
testen. Je zult in hoofdstuk 11 zien hoe je een opgeslagen procedure aanroept vanuit 
applicatiecode. 


10.5 Opgeslagen procedures 


Transact-SQL is de Microsoft-variant van SQL, aangevuld met een aantal elementen 
uit procedurele talen om triggers en opgeslagen procedures te schrijven. In Trans- 
act-SQL beginnen namen van variabelen en parameters met een @. Dus WorkID is 
een kolomnaam, maar @ WorkID is in Transact-SQL een variabele of een parameter. 
Een parameter is een waarde die aan een opgeslagen procedure wordt doorgegeven 
wanneer die wordt aangeroepen. Een variabele is een waarde die in een opgeslagen 
procedure of trigger gebruikt wordt. Commentaar geef je in Transact-SQL aan tus- 
sen /* en */ of achter twee mintekens - als het commentaar slechts een regel beslaat. 


10.5.1 De opgeslagen procedure InsertCustomerAndinterests 
Figuur ro-1o toont een opgeslagen procedure die gegevens voor een nieuwe klant in 
CUSTOMER opslaat en daarna gegevens van die klant in CUSTOMER ARTIST_INT 
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opslaat, waarbij die klant wordt gekoppeld aan alle kunstenaars met een bepaalde 
nationaliteit. 

Aan deze procedure worden vijf parameters doorgegeven: @NewLastName, 
@NewFirstName, @NewAreaCode, @NewPhoneNumber en @ Nationality. De eer- 
ste vier parameters zijn de nieuwe klantgegevens en de vijfde is de nationaliteit van 
de kunstenaars waarin de nieuwe klant geïnteresseerd is. 

De opgeslagen procedure maakt ook gebruik van drie variabelen: @ RowCount, 
@ArtistID en @CustomerlD. Deze variabelen worden gebruikt om het aantal rijen 
op te slaan en de waarde van Artist[D en van CustomerID. 

De eerste taak die deze opgeslagen procedure moet uitvoeren, is bepalen of de 
klant al bestaat. Als de waarde van @RowCount in het eerste SELECT-statement gro- 
ter is dan o, dan bestaat er al een rij voor die klant. Als dat zo is, wordt er verder niets 
gedaan en wordt een foutmelding getoond, The Customer is already in the database, 
waarna de procedure wordt beëindigd (via het RETURN-statement). Deze foutmel- 
ding is zichtbaar in SQL Server Management Studio, maar meestal niet in applica- 
ties die deze procedure aanroepen. In die programma’s moet een parameter of iets 
anders worden gebruikt om de foutmelding aan de gebruiker te laten zien. Een be- 

spreking hiervan voert te ver voor dit boek. 

Als de klant nog niet bestaat, zal de procedure de nieuwe gegevens in de tabel 
dbo.CUSTOMER plaatsen en een nieuwe waarde voor CustomerID opbergen in de 
variabele @CustomerlD. 

SQL Server laat tabelnamen intern voorafgaan door de naam van de gebruiker die 
ze heeft gemaakt. Het voorvoegsel .dbo wordt hier gebruikt om te garanderen dat de 
door de eigenaar van de database (dbo = database owner) gemaakte tabel CUSTOMER 
wordt verwerkt. Als je het voorvoegsel dbo niet gebruikt en de gebruiker die de opge- 
slagen procedure aanroept een tabel met de naam CUSTOMER heeft gemaakt, dan 
wordt die tabel gebruikt in plaats van de tabel van de dbo. 

De tweede SELECT in Figuur ro-1o heeft tot doel de waarde van de surrogate key 
CustomerID op te halen, die is gemaakt door het INSERT-statement. Een andere 
optie is om de functie @ @lIdentity te gebruiken. Dit is een ingebouwde functie van 
SQL Server die de waarde levert van de meest recentelijk gemaakte surrogaatsleutel. 


Je kunt het tweede SELECT-statement met behulp van deze functie vervangen door 
de expressie: 


Set @CustomerID = @@ldentity 


De juiste intersectietabelrijen worden gemaakt door een cursor te maken voor een 
SQL-statement dat alle ARTIST-rijen ophaalt waarvoor Nationality gelijk is aan de 
parameter @ Nationality. De cursor wordt geopend en op de eerste rij geplaatst door 
FETCH NEXT aan te roepen. De cursor wordt daarna verwerkt in een WHILE-lus. 
De statements tussen BEGIN en END in deze lus worden herhaald tot SQL Ser- 
ver aangeeft dat het einde van de gegevens is bereikt door de waarde van de functie 
@@FETCH.- STATUS op nul te zetten. 
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ìmerAndInterests 
har(25), 
har(25), 


har(3), 


ber Char(8), 
Varchar(100), 
nality Char(30) 
AS 
DECLARE @RowCount AS Int 
DECLARE @ArtistID AS Int 
DECLARE @CustomerlD AS Int 
Controleer of deze Customer al in de database zit 
SELECT @RowCount COUNT (*) 
FROM dbo.CUSTOMER 
WHERE LastName @NewlLastName 


AND FirstName = @NewFirstName 
AND AreaCode = 


AND PhoneNumbder @NewPhoneNumbder 


NewAreaCode 


AND Email = @NewEmail; 


Als @RowCount > O dan bestaat deze Customer al 

IF (@RowCount > 0) 

BEGIN 
PRINT * The Customer is already in the database. 
PRINT *"' 


PRINT * Customer Last Name = _"+@NewLastName 
PRINT * Customer First Name = _‘+@kewfirstName 
PRINT ** 
RETURN 

END 


Als @RowCount = O dan bestaat deze Customer nog niet 
ELSE 
BEGIN 
Voer de nieuwe Customer-gegevens in 
INSERT INTO dbo.CUSTOMER 
{LastName, FirstName, AreaCode, PhoneNumber, Email) 
VALUES( @NewLastName, @NewFirstName, @NewAreaCode. 
@NewPhoneNumber, @lewEmail); 
/* Vraag om een nieuwe waarde voor */ 
/* de surrogaatsleutel CustomerlD */ 


SELECT @CustomerID = CustomerlD 
FROM dbo.CUSTOMER 
WHERE LastName = @NewLastName 
AND FirstName = @NewfirstName 


AND AreaCode = @NewAreaCode 
AND PhoneNumber = @NewPnhoneNumber 
AND Email = @NewEma il; 


PRINT ** 
PRINT * The new Customer is now in the database. * 


Figuur 10-10 De opgeslagen procedure InsertCustomerAndinterests 
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PRINI 

PRINT * Customer Last Name = jk 

PRINT * Customer First Name ir 

PRINT 

Maak een record voor de tussentabel voor elke geschikte Artist 
DECLARE ArtistCursor CURSOR FOR 

SELECT ArtistiD 

FROM dbo, ARTIST 

WHERE Nationality=@Nationality 


Verwerk elke geschikte Artist 
OPEN ArtistCursor 
FETCH NEXT FROM ArtistCursor INIO @Artast ID 
WHILE @@FETCH_STATUS — 0 


BEGIN 
INSERT INTO dbo.CUSTOMER ARTIST _INT(Artist 1D, CustomerlD) 
VALUES(@ArtistID, @CustomerlD); 
PRINT ** 
PRINT * _ New CUSTOMER_ARTIST_INT row added. 
PRINT *” 
PRINT * ArtistID “+CONVERT (Char(6), @ArtistID) 
PRINT * CustomeriD = "+CONVERT(Char(6), @CustomerlD) 
PRINT ** 


FETCH NEXT FROM ArtistCursor INTO @ArtistID 


t IC 
END 
CLOSE ArtistCursor 
DEALLOCATE ArtistCursor 

END 


Figuur 10-10 (vervolg) 


Tijdens elke herhaling wordt een nieuwe rij in de intersectietabel CUSTOMER-_AR- 
TIST_INT ingevoegd. Het statement FETCH NEXT aan het einde van het blok ver- 
plaatst de cursor naar de volgende rij. 

Om de opgeslagen procedure InsertCustomerAndInterests in de database VRG 
te maken, maak je een nieuw script met de naam VRG-Create-Stored-Procedures.sql 
met de SQL-code van Figuur 10-10. Gebruik de Parse-knop om de SQL-code te veri- 
fiëren, bewaar de code voor je hem laat uitvoeren. Zorg ervoor dat de VRG-database 
is geselecteerd in selected in de lijst met Available Databases en gebruik dan de knop 
Execute om de stored procedure te maken. 

Om de InsertCustomerAndInterests-procedure aan te roepen met de gege- 
vens van een nieuwe klant met de naam Michael Bench, gebruik je het volgende 
SQL-statement: 


EXEC InsertCustomerAndInterests 
@NewLastName = ‘Bench’, @NewFirstName = 'Michael', 
@NewAreaCode = '206', @NewPhoneNumber = '876-8822', 
@NewE-mail = '‘Michael.Bench@somewhere.com', 
@Nationality = ‘French’; 
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In Figuur 1o-11 is te zien hoe deze opgeslagen procedure met behulp van de SQL Ser- 
ver Management Studio wordt aangeroepen om een nieuwe klant toe te voegen die 
is geïnteresseerd in Amerikaanse kunstenaars. Er worden parameters doorgegeven 
met de getoonde waarden. In de uitvoer in Figuur 1o-11 is te zien dat klant Michael 
Bench is toegevoegd aan de tabel CUSTOMER. Ook is te zien dat er nieuwe rijen zijn 
toegevoegd aan de tabel CUSTOMER ARTIST_INT. 


De Execute-knop IE 


| De Parse-knop 


‚ Het SOL-statement 
‚ om de opgeslagen 
| procedure uit te voeren 


| De uitvoer 
van de opgeslagen E 
procedure 


De map 
\ Stored Procedures |” 


Het object 7Á 
| dbo.InsertCustomerAndinterests 


vant nsand weram gi) wr edm Dre 
we cn an ze 


Figuur 10-11 Uitvoer procedure InsertCustomerAndinterests 


Je kunt het voorgaande EXEC-statement opnemen in het script VRG-Create-Stored- 
Procedures.sql en vervolgens laten uitvoeren. Wanneer je meer dan één statement in 
een geopend script hebt, kun je ze één voor één laten uitvoeren door eerst het state- 
ment te selecteren dat je wilt gebruiken. De Parse- en Execute-knop werken dan al- 
leen op het statement dat je hebt geselecteerd. Je kunt ook meer dan één statement 
selecteren en Parse of Execute op die groep statements laten uitvoeren. 


10.6 Triggers 


SQL Server ondersteunt alleen INSTEAD OF- en AFTER-triggers, maar geen BEFO- 
RE-trigger. Een tabel kan een of meer AFTER-triggers hebben voor insert, update en 
delete — AFTER-triggers kunnen niet aan views worden toegekend. Een view of een 
tabel mag maximaal één INSTEAD OF-trigger hebben voor elke uitvoerende actie 
(invoegen, bijwerken of verwijderen). 

Triggers kunnen in SQL Server de betreffende transacties terugdraaien. Al het 
werk van de transactie die heeft geleid tot uitvoering van de trigger, wordt ongedaan 
gemaakt als de trigger een ROLLBACK-commando uitvoert. Als de trigger instruc- 
ties bevat na het ROLLBACK-commando, zullen die instructies worden uitgevoerd. 
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Instructies in de transactie die op het statement volgen dat heeft geleid tot uitvoering 
van de trigger, zullen echter niet worden uitgevoerd. 

Voor insert- en updatetriggers geldt dat de nieuwe waarden voor alle kolommen 
van de tabel die wordt verwerkt, worden opgeslagen in een pseudotabel met de naam 
inserted. Als we bijvoorbeeld een nieuwe rij toevoegen aan de tabel ARTIST, dan 
zal de pseudotabel inserted vijf kolommen hebben: LastName, FirstName, Nationa- 
lity, DateOfBirth en DateDeceased. Voor update- of delete-triggers geldt dat de oude 
waarden voor alle kolommen van de tabel die wordt bijgewerkt of verwijderd, wor- 
den opgeslagen in de pseudotabel deleted. Je zult in de volgende voorbeelden zien 
hoe je deze pseudotabellen gebruikt. 

De volgende vier paragrafen lichten vier triggers toe voor elk van de vier trig- 
gerfuncties die we in hoofdstuk 7 beschreven. De beste manier om deze triggers 
te maken, is door ze in een SQL-script te typen (met CREATE TRIGGER of ALTER 
TRIGGER als het eerste statement) in de SQL-editor van SQL Server Management 

Studio. Een andere manier om een trigger te maken, is door rechts te klikken op de 
map Triggers van een tabel. 


10.6.1 Een trigger voor het instellen van defaultwaarden 

Triggers kunnen worden gebruikt voor het instellen van defaultwaarden die inge- 
wikkelder zijn dan wat er met de constraint Default kan worden ingesteld voor een 
kolomdefinitie. View Ridge heeft bijvoorbeeld een prijsbeleid dat zegt dat de stan- 
daard-AskingPrice van een werk afhankelijk is van of het werk al eerder in de galerie 
is geweest. Is dat niet het geval, dan is de standaard-AskingPrice tweemaal de Aquisi- 
tionPrice. Is dat wel het geval, dan is de standaardprijs de hoogste van twee waarden: 
tweemaal de AquisitionPrice, of de AquisitionPrice plus de gemiddelde nettowinst 
voor het werk in het verleden. 

De AFTER-trigger die je in Figuur 1o-12 ziet, implementeert dit prijsbeleid. In 
deze code wordt de term AFTER gebruikt, mag je mag ook FOR gebruiken. In beide 
gevallen gaat het om een AFTER-trigger. 

Als de variabelen in de trigger gedeclareerd zijn, worden de nieuwe waarden van 
WorkID en AquisitionPrice opgehaald uit de pseudotabel inserted. Daarna wordt een 
SELECT FROM dbo.TRANS uitgevoerd om het aantal rijen met de gegeven WorkID 
te tellen. 

Deze trigger gebruikt de systeemfunctie @ @rowCount, die het aantal rijen levert 
dat in het voorafgaande T-SQL-statement werd verwerkt. Deze waarde moet meteen 
worden gecontroleerd nadat het statement is uitgevoerd, of de waarde moet in een 
variabele worden opgeslagen, zodat deze later kan worden gecontroleerd. De trigger 
maakt hier meteen gebruik van de waarde van @@rowCount. 

De variabele @PriorRowCount wordt ingesteld op @@rowCount min r, omdat 
dit een AFTER-trigger is en de nieuwe rij al in de database zal bestaan. De uitdruk- 
king (@@rowCount — 1) levert dus het juiste aantal rijen in TRANS vóór de insert. 

We controleren of het werk nieuw is. Zo ja, dan wordt @newAskingPrice inge- 
steld op tweemaal de AquisitionPrice. 
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AS Int, 
AS Int, 
oni0 AS Int, 


Transa niD, 
tionPrice = AcquisitionPrice 
Workl0D 


hier eerder is geweest 


dbo. TRANS AS T 
WHERE T.WorkiD @Wo 


Oma 


dit een AFTER-triggeris, omvat wcount de nieuwe rij 


keer dat het werk in de gallerie is 
e keer de aanschafprijs 
@AcquisitionPrice) 


t 
sKingPrice bepalen 


Het werk ís nier eerder gewe 


We moeten de waarde van @he 


BEGIN 
SELECT @SumNetProfit = SUM(NetProf it) 
FROM dbo.ArtistWorkNetView AUNV 


WHERE AWNV.WorkID = @worklD 
GROUP BY AWNV.WorkID; 
SET @AvgNetProfit = (@SumNetProfit / @PriorRowCount); 
s nu de grootste waarde voor de vraagprijs 
cquisitionPrice + @AvgNetProfit) > 
(2 * @AcquisitionPrice)) 
SET @newAskingPrice = (@AcquisitionPrice + @AvghetProf it) 
ELSE 
SET @NewAskingPrice = (2 * @AcquisitionPrice) 
END 


Update TRANS met de waarde van AskingPrice 
UPDATE dbo.TRANS 
SET AskingPrice = @NewAskingPrice 
WHERE TransactioniD = @fransactioniD; 


INSERT is klaar 
BEGIN 
PRINT 
PRINT * INSERT complete. 
PRINT ©" 
PRIKT * TransactioniD = * + CONVERT(Char(6), @TransactionlD) 
PRINT * WorkID = * + CONVERT(Char(6), @workID) 


PRINT * Acquisition Price = * + CONVERT(Char(12), @AcquisitionPrice) 
PRINT * Asking Price = * + CONVERT(Char(12), @rewAskingPrice) 
PRINT ** 

END 


END 


Figuur 10-12 De trigger TRANS _AfterinsertSetAskingPrice 
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Als het werk eerder in de galerie is geweest, moeten we de @newAskingPrice be- 
rekenen. Dus als @ PriorRowCount groter dan o is, kwamen er TRANS-rijen voor dit 
werk voor in de database. De view ArtistWorkNetView (zie paragraaf 7.7.4) wordt ge- 
bruikt om de som van NetProfit op te halen. De ingebouwde functie Average is niet 
bruikbaar, want deze zou het gemiddelde berekenen met @@rowCount, in plaats 
van met @PriorRowCount. De twee mogelijke waarden van @ NewAskingPrice wor- 
den daarna vergeleken en @NewAskingPrice krijgt de grootste van deze waarden. 
TRANS wordt ten slotte bijgewerkt met de berekende waarde van @NewAskingPri- 
ce voor AskingPrice. 

Om de trigger te testen voegen we een nieuw werk toe met de volgende code: 


INSERT INTO WORK VALUES( 
‘Spanish Dancer’, '635/750', ‘High Quality Limited Print', 
‘American Realist style - From work in Spain', 11); 

-- Obtain the new WorkID 

SELECT WorkID 


FROM dbo.WORK 

WHERE ArtistID = 11 
AND Title = ‘Spanish Dancer’ 
AND Copy = '635/750'; 


-- Use the new WorkID value (597 in this case) 
INSERT INTO TRANS (DateAcquired, AcquisitionPrice, WorkID) 
VALUES ('06/8/2008', 200.00, 597); 


Deze trigger levert nuttige functionaliteit voor de galerie. Het personeel van de gale- 
rie wordt heel wat handmatig werk bespaard door het prijsbeleid op deze manier te 
implementeren. Ook zal de nauwkeurigheid van de resultaten waarschijnlijk beter 
zijn. 


10.6.2 Een trigger voor het handhaven van een data constraint 

Galerie View Ridge houdt een lijst bij met accounts van klanten die problemen op- 
leveren — klanten die niet op tijd hebben betaald, of die andere problemen hebben 
opgeleverd voor de galerie. Als een klant die op de zwarte lijst staat in de database 
wordt ingevoerd, dan wil de galerie dat de ingevoegde of bijgewerkte klantengege- 
vens worden teruggedraaid en dat er een melding wordt weergegeven. 

Om dit beleid te kunnen handhaven, voegen we een kolom toe aan de tabel CUS- 
TOMER met de naam isProblemAccount. Deze kolom heeft het Bit-datatype, dat de 
waarden NULL, o, of 1 kan hebben. Een o betekent dat alles in orde is, 1 betekent dat 
er met dit account een probleem is. Het lijkt erop dat klant Melinda Gliddens proble- 
men heeft met de betaling dus we geven isProblemAccount de waarde 1: 


ALTER TABLE dbo.CUSTOMER 
ADD isProblemAccount Bit NULL DEFAULT '0'; 
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UPDATE dbo.CUSTOMER 
SET isProblemAccount = 0; 
UPDATE dbo.CUSTOMER 
SET isProblemAccount = 1 
WHERE LastName = 'Gliddens' 
AND FirstName = ‘Melinda! 
SELECT CustomerID, LastName, FirstName, isProblemAccount 
FROM dbo.CUSTOMER; 
isProblemAccount 


inst Name 
Janes Jeffrey 


Eh Ken Smith David 0 
‚3 | 1015 Twilight Tiffany 0 
‚4_| 1033 Smathers Fred 0 
‚5_| 1034 Frederic... MayBeth 0 
‚6 _| 1036 Waming Selma _ 0 
‚7 _| 1037 Wu Susan 0 
‚8 _| 1040 Gray Donald 0 
of 1041 Johnson Lynda LI) 
to | 1051 Wilkens Chris ij 
(11 _| 1052 Bench _ Michael 0 

Gliddens Melinda 1 


Figuur 10-13 Resultaat SELECT-statement 


Het resultaat van dit SELECT-statement staat in Figuur 10-13. 


We maken nu een trigger op TRANS met de naam TRANS. ChecklsProblemAc- 
count. Als een klant een aankoop doet, gaan we met deze trigger na of er een pro- 
bleem is met zijn of haar account. Als dat het geval is, wordt de transactie ongedaan 
gemaakt en wordt er een mededeling getoond. De triggercode in Figuur 10-14 voert 
dit beleid uit. 


EATE TRIGGER TRANS _ChecklsProblemAccount 


SET NOCOUNT ON: 

DECLARE @TransactianlD AS Int. 
@Customer 1D AS Int, 
@isProblemAccountAS Bit 
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SELECT @fransactionlD = TransactionID, 
@CustomeriD = CustomerlD 
FROM inserted; 


/* Deze trigger wordt geactiveerd door elke update van 
* Ook als bij die update geen Customer betrokken is, 


update van AskingPrice door de 

* TRANS _AfterInsertSetAskingPrice trigger. 

Zorg daarom dat er altijd een Customer meedoet 
“in the update van TRANS 


Controleer of Customer ID is 
Doe geen ROLLBACK voor de 


en zo ja RETURN 


IF (@CustomeriD IS NULL) RETURN 


Geldig CustomerlD 
Haal een waarde op voor @isProblemAcocunt. 


SELECT @isProblemAccount = isProblemAccount 
FROM _dbo.CUSTOMER AS C 
WHERE C.CustomerlD = @CustomerlD; 


IF (@isProblemAccount = 1) 
Dit is een probleemaccount 
- Doe een rollback voor de transactie en geef een melding 


BEGIN 
ROLLBACK TRANSACT ION 
PRINT ** 
PRINT * Transaction canceled.* 
PRINT ** 
PRINT * _CustomerlD = * + CONVERT(Char(6), @Customer 1D) 
PRINT ** 
PRINT * Refer customer to the manager immediately." 
PRINT ** 
RETURN 
END 
ELSE 
- Dit is geen probleemaccount 
BEGIN 
PRINT *’ 


PRINT * Transaction complete.” 
PRINT * Transactionl0 = * + CONVERT (Char(6), @Transactionl0D) 
PRINT * CustomerID = * + CONVERT (Cnar(6), @Customer10) 
PRINTS) 
PRINT * Thank the customer for their business.” 
PRINT ** 
END 
END 


Figuur 10-14 De code voor de trigger TRANS _CheckisProblemAccount 
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De triggercode in Figuur 10-14 heeft een interessante eigenschap. De trigger wordt 
geactiveerd door elke wijziging in de gegevens van TRANS, ook door wijzigingen die 
worden veroorzaakt door andere triggers zoals TRANS AfterInsertSetAskingPrice. 
Maar in die trigger is er geen klant in het spel. Daarom moeten we in de trigger van 
Figuur 1o-14 controleren of er daadwerkelijk een klant betrokken is bij de transactie. 
Dit gebeurt in de volgende regel: 


IF (@CustomerID IS NULL) RETURN 


Merk op dat als er geen klant bij deze trigger is betrokken, we deze alleen verlaten 
—er vindt geen rollback plaats. Als je triggers schrijft, realiseer je dan dat ze ook in 
andere situaties kunnen worden geactiveerd dan die waarvoor je ze in eerste instan- 
tie bedoelde. 

OK, laat Melissa een aankoop doen, en kijk wat er gebeurt. 


UPDATE TRANS 

SET DateSold = '11/18/2008', 
SalesPrice = 475.00, 
CustomerlD 1056 

WHERE TransactionID = 229; 


Het resultaat zie je in Figuur ro-15. Het ziet ernaar uit dat Melinda met de manager 
moet praten over haar account! 


WE alii 
De Execute-knop 
De Parse-knop = : 


4 | 
De SQL-opdrachten 
van de trigger 


De uitvoer van 
de trigger 


ed ren 
Tj ome pamrearzet 
Trans Oester 


De map 
dbo.TRANS | Triggers 


Het trigger-object 
TRANS_ChecklisProblemAccount 
Les 


VEIIEDD WTA OQ m3 0 Cron | 
TT vam cn an pel 


Figuur 10-15 Resultaat van de trigger TRANS_CheckisProblemAccount 
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Het gebruik van een tabel met geldige of ongeldige waarden is flexibeler en dyna- 
mischer dan het opnemen van dergelijke waarden in een CHECK-constraint. Neem 
bijvoorbeeld de CHECK-constraint voor Nationality-waarden in de tabel ARTIST. De 
manager van de galerie zal de CHECK-constraint moeten veranderen met het state- 
ment ALTER TABLE als hij of zij meer nationaliteiten wil toestaan voor kunstenaars. 
De manager van de galerie zal in werkelijkheid waarschijnlijk een consulent moeten 
inhuren om deze constraint te wijzigen. 

Een betere werkwijze is het om de toegestane waarden van Nationality in een tabel 
te plaatsen, zoals ALLOWED_NATIONALITY. Schrijf dan een trigger zoals die in 
Figuur 10-14 voor het handhaven van de constraint dat nieuwe waarden van Nationa- 
lity moeten bestaan in ALLOWED_NATIONALITY. De eigenaar kan dan simpelweg 
waarden aan de tabel ALLOWED_NATIONALITY toevoegen, of daar waarden uit 
verwijderen, als hij of zij de toegestane kunstenaars wil veranderen. 


10.6.3 Een trigger voor het bijwerken van een view 

De problemen van het bijwerken van views bespraken we al in hoofdstuk 7. Een van 
deze problemen heeft te maken met het bijwerken van via joins gemaakte views — 
het DBMS kan normaliter niet weten hoe het de tabellen moet bijwerken waarop de 
join is gebaseerd. Soms is echter applicatiespecifieke kennis nodig om te bepalen 
hoe een aanvraag voor het bijwerken van een samengevoegde view moet worden 
geïnterpreteerd. 

Kijk eens naar de view CustomerlnterestsView die je in Figuur 10-7 ziet. Deze 
bevat rijen van CUSTOMER en ARTIST, die zijn samengevoegd via hun inter- 
sectietabel. CUSTOMER.LastName krijgt de alias CustomerLastName en ARTIST. 
LastName krijgt de alias ArtistLastName. 

Een aanvraag voor het wijzigen van de achternaam van een klant in Customer- 
InterestsView kan geïnterpreteerd worden als een aanvraag voor het wijzigen van 
LastName in de onderliggende tabel CUSTOMER. Een dergelijke aanvraag kan ech- 
ter alleen worden verwerkt als de waarde van LastName uniek is in Customer. Is dat 
niet het geval, dan kan de aanvraag niet worden verwerkt. 

De INSTEAD OF-trigger die je in Figuur 10-16 ziet, implementeert deze logica. 
Eerst worden de nieuwe en oude waarden van CustomerLastName in Customerln- 
terestsView opgehaald. Daarna wordt een gecorreleerde subquery met EXISTS ge- 
bruikt om te bepalen of de waarde van CUSTOMER.LastName uniek was. Zo ja, dan 
wordt de naam gewijzigd. Zo niet, dan wordt de update niet uitgevoerd. 

De trigger moet getest worden aan de hand van gevallen waarbij de naam wel en 
niet uniek is. Figuur ro-17 laat het geval zien waarbij de klantnaam uniek was. Melis- 
sa Gliddens is met Michael Bench getrouwd en ze wil haar achternaam veranderen. 
Hiervoor gebruiken we het volgende SQL-stateUPDATE dbo.CustomerInterestsView 
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CREATE TRIGGER CIV _ChangeCustomerLastName 
ON dbo.CustomerInterestsView 


INSTEAD OF 
AS 
BEGIN 


UPDATE 


SET NOCOUNT ON: 


DECLARE 


Haal 
SELECT 


FROM inserted; 


SELECT 


@NewCustomerLastName AS Char(25), 
@OldCustomerLastName AS Char(25) 
de nie en oude naam op 
CustomerlastName = CustomerlastName 


@OldCustomerLastName = CustomerLastName 


FROM deleted; 


Tel het aantal klanten met dezelfde naam 


SELECT 


FROM dbo.CUSTOMER AS CI 


WHERE Cl. 


IF (@@ro 


LastName = @OldCustomerlastName 
AND EXISTS 
(SELECT 
FROM dbo.CUSTOMER AS C2 
WHERE C1.LastName = C2.LastName 


AND Cl.CustomerID <> C2.CustomerID); 


wCount = 0) 


-- De achternaam van de klant is uniek 
Update het record van de klant 


BEGIN 
UPDATE 


SET Las 


WHERE 


PRINT 
PRINT 
PRINT 
PRINT 
PRINT 
PRINT 
PRINT 

END 

ELSE 


dbo.CUSTOMER 
tName = @NewCustomerlLastName 
LastName = @OldCustomerlLastName; 


Print een mededeling 


IE 


The Customer last name has been changed." 
“ Former Customer Last Name = ‘+@0ldCustomerlLastName 


Updated Customer Last Name = ‘+@NewCustomerlLastName 


e 


-- De klantnaam is niet uniek 
-- Draai de transactie terug en toon een mededeling 


BEGIN 
PRINT 
PRINT 
PRINT 
PRINT 
PRINT 
PRINT 
PRINT 

END 

END 


Figuur 10-16 


“ Transaction cancelled.’ 


Customer Last Name = ‘+@NewCustomerlastName 


The customer last name is not unique.’ 


Het SQL-statement voor de trigger CIV_ChangeCustomer LastName 
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SET CustomerLastName = 'Bench' 
WHERE CustomerLastName = 'Gliddens'; 


Merk op dat deze UPDATE wordt uitgevoerd op de view. In Figuur 10-17 zie je dat 
Melissa nu Bench heet. 


De Execute-knop 


De Parse-knop 


De SQL-opdrachten 
van de trigger 


k E 


n . 
heteske 


t 


De uitvoer van 
de trigger 


De map 
Views Triggers 


Het trigger-object 
CIV_ChangeCustomerName 


Figuur 10-17 Resultaat van de trigger CIV_ChangeCustomerLastName 


10.6.4 Een trigger voor het afdwingen van een child constraint 

Het ontwerp voor View Ridge omvat een verplicht-tot-verplichte relatie tussen WORK 
en TRANS. Elk WORK moet een TRANS hebben voor het opslaan van de prijs en 
de aankoopdatum van het kunstwerk, en elke TRANS moet aan een WORK-parent 
zijn gerelateerd. Figuur 10-18 toont de taken die moeten worden uitgevoerd om deze 
constraint af te dwingen — deze figuur is gebaseerd op de sjabloon uit Figuur 6-23(b). 


Een nieuwe TRANS moet een geldige WorklD 
hebben (wordt door het DBMS afgedwongen). 


Invoegen 


Sleutel of externe 
sleutel wijzigen 


Maak een TRANS-rij. 


Geen probleem, want WorkID is 
een surrogate key. 


Nooit toegestaan, want een TRANS kan niet 
aan een ander WORK worden toegekend. 


Verwijderen Een WORK dat TRANS-children heeft | De laatste child kan niet worden verwijderd. 
kan niet worden verwijderd (wordt (Er kunnen wegens het beleid van de galerie 
door het DBMS afgedwongen wegens | feitelijk helemaal geen TRANS-gegevens 


het ontbreken van CASCADE DELETE) | worden verwijderd.) 


EN 


Figuur 10-18 De M-M relatie tussen WORK en TRANS handhaven 
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Het CREATE TABLE-statement voor TRANS (Figuur 10-4) definieert dat TRANS. 
WorkID NOT NULL is en het definieert de FOREIGN KEY-constraint zonder cas- 
cading deletes. Het DBMS zal er daarom voor zorgen dat elke TRANS een WORK- 
parent heeft. We hoeven ons dus niet bezig te houden met het afdwingen van de 
insert op TRANS of de delete uit WORK. Zoals in Figuur 10-18 vermeld, zal het 
DBMS dat voor ons doen. We hoeven ons ook niet bezig te houden met updates op 
Work. WorklD, want dat is een surrogate key. 

Er blijven drie constraints over die door triggers moeten worden afgedwongen: (1) 
er moet een TRANS-rij komen als er een nieuw WORK wordt gemaakt, (2) er moet 
voor gezorgd worden dat TRANS.WorkID nooit zal veranderen en (3) er moet voor 
gezorgd worden dat de laatste TRANS-child van een WORK nooit zal worden verwij- 
derd. We kunnen de tweede constraint afdwingen door een trigger te schrijven voor 
het updaten van TRANS die controleert of er een verandering is opgetreden in Work- 
ID. Is een dergelijke wijziging opgetreden, dan kan de trigger deze terugdraaien. 

Wat betreft de derde constraint: de galerie heeft een bedrijfsbeleid dat er nooit 
TRANS-gegevens worden verwijderd. We moeten dus niet alleen het verwijderen 
van de laatste child verbieden, we moeten het verwijderen van welke child dan ook 
verbieden. We kunnen dat doen door een trigger te schrijven voor het verwijderen 
uit TRANS die elke verwijderpoging meteen zal terugdraaien. (We zouden de dele- 
teconstraint op de in Figuur 7.32 en 7.33 in hoofdstuk 7 getoonde manier kunnen 
afdwingen via views, als de galerie verwijderingen uit TRANS zou toestaan.) De trig- 
gers voor het afdwingen van de tweede en derde constraint zijn eenvoudig en we zul- 
len ze daarom overlaten voor oefening 28 en 29. 

De eerste constraint is echter een probleem. We kunnen een trigger schrijven 

voor WORK INSERT die een default-TRANS-rij maakt. Deze trigger zal echter wor- 
den aangeroepen voordat de applicatie zelf de kans krijgt een rij in TRANS te maken. 
De trigger zal een TRANS-rij maken en de applicatie zal er daarna misschien nog 
een maken. We kunnen de duplicering verhelpen door een trigger te schrijven voor 
TRANS die de door de WORK-trigger gemaakte rij zal verwijderen in het geval dat 
de applicatie zelf een rij maakt. 
Een beter ontwerp is te eisen dat de applicaties de combinatie van WORK en TRANS 
maken via een view. We kunnen bijvoorbeeld een view maken met de naam Wor- 
kAndTransView (we zullen de code toevoegen aan ons script VRG-Create-Views.sql 
en vandaar laten uitvoeren): 


CREATE VIEW WorkAndTransView AS 
SELECT Title, Copy, Medium, [Description], ArtistID, 
DateAcquired, AcquisitionPrice 
FROM WORK AS W JOIN TRANS AS T 
ON W.WorkID = T.WorkID; 
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Het DBMS zal niet in staat zijn een insert op deze view te verwerken. We kunnen 
echter wel een INSTEAD OF-trigger definiëren voor het verwerken van de insert. 
Onze trigger, met de naam WATV_InsertTransaction With Work, zal zowel een nieu- 
we rij in WORK maken als de nieuwe, vereiste child in TRANS. Je ziet de code voor 
deze trigger in Figuur ro-19. 

Merk op dat toepassingen bij deze oplossing niet rechtstreeks rijen in WORK mo- 
gen invoegen. Ze zullen dat altijd moeten doen via WorkAndTransView. 

Om onze trigger te testen, voegen we een nieuw werk toe aan de VRG-database. 
Melissa, inmiddels mevrouw Bench, heeft de problemen met haar account opgelost 
en koopt Color Floating in Time van Horiuchi. 


UPDATE dbo.CUSTOMER 

SET isProblemAccount = 0 

WHERE LastName = ‘Bench! 

AND FirstName = 'Melinda'; 

UPDATE TRANS 

SET DateSold = '11/18/2008' , 
SalesPrice = 475.00, 
CustomerID = 1053 
WHERE TransactionID = 229; 


Merk op dat de het voorgaande UPDATE-statement de TRAN- ChecklsProblem- 
Account-trigger activeerde, maar omdat Melinda nu een goede klant is wordt de 
transactie geaccepteerd. 

We zullen nu de galerie opnieuw voorzien van een exemplaar van Color Floating 
in Time. 


INSERT INTO WorkAndTransView 
VALUES( 
‘Color Floating in Time', '493/750', ‘High Quality Limited 
Pinninitaes 
‘Northwest School Abstract Expressionist style', 18, 
‘02/05/2009', 250.00); 


Het resultaat hiervan zie je in Figuur 10-20. Merk op dat de trigger WATV_Insert- 
TransactionWithWork in feite twee andere triggers activeert. Eerst de INSERT-trigger 
TRANS. AfterInsertSetAskingPrice, die vervolgens de UPDATE-trigger TRANS 
CheckIsProblemAccount activeert. Omdat er geen klant is betrokken bij deze trans- 
actie, zal deze trigger snel klaar zijn (zie de discussie in paragraaf ro.6.2). Maar de 
trigger TRANS. AfterInsertSetAskingPrice wordt uitgevoerd en bepaalt de vraagprijs 
voor het nieuwe werk. Daarom zie je het resultaat van twee triggers in de uitvoer in 
Figuur 10-20. 
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CREATE TRIGGER WATY _InsertTransactionWithwork 


ON dbo.WorkAndlransV iew 
INSTEAD OF INSERT 


AS 
BEGIN 
SET NOCOUNT ON; 
DECLARE @TransactionlD AS Int, 
@WorklD AS Int, 
@rlitle AS Char(35), 
Copy AS Char(12), 


ad î um AS Char(35) 
@Description AS Varchar( 1000), 
DArtistID AS Int, 


DateAcquired AS Datel ime, 
@AcquisitionPrice AS Numeric(8,2), 
@AskingPrice AS Numeric(8,2) 


Haal de beschikbare waarden op van de Insert op de view. 


SELECT @Title Title, @Copy = Copy, @Medium Medium, 
@Description [Description] 
@ArtistID Artist10, @DateAcquired =DateAcquired, 
| q 


@AcquisitionPrice AcquisitionPrice 
FROM inserted: 


Maak een nieuwe rij in WORK 
INSERT INTO WORK VALUES( 
@Title, @Copy. @Medium, @Description, @ArtistID): 


Maak surrogaatsleutel Workl0 met behulp van de functie @@ldentity 
SET @WorklD @C@ldentity; 


- Maak een nieuwe rij in TRANS 
Merk op dat INSERT de trigger 
TRANS _AfterInsertSetAskingPrice activeert 


INSERT INTO TRANS (DateAcquired, AcquisitionPrice, WorkID) 
VALUES(@DateAcquired, @AcquisitionPrice, @workID); 


Maak surrogaatsleutel TranasctioniD 
SET @TransactionlD = @@ldentity: 


Haal de nieuwe AskingPrice op die door 
-- TRANS_AfterInsertSetAskingPrice is berekend 
SELECT @AskingPrice = AskingPrice 
FROM TRANS 
WHERE TransactionlD = @TransactionlD; 


Toon het resultaat 
PRINT * The new work has been inserted into WORK and TRANS." 
PRINT ** 


PRINT * TransactionlD "+CONVERT(Char(6), @TransactionlD) 


PRINT * WorklD = ‘+CONVERT(Char(6), @worklD) 

PRINT * Artist ID = "+CONVERT(Char(6), @Artist ID) 

PRINT * Title = '+@Title 

PRINT * Copy = '+@Copy 

PRINT * Medi um = '+@Medium 

PRINT * Description = '‘+@Description 

PRINT * DateAcqui red = '+CONVERT(Char(12), @DateAcquired) 
PRINT * __ Acquisition Price = '+CONVERT(Char(12), @AcquisitionPrice) 
Ne Ë Asking Price = '+CONVERT(Char(12), @AskingPrice) 

1 


Figuur 10-19 De code van de trigger WATV_insertTransactionWithWork 
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De Execute-knop 
te 7 Sv je al AEK: nme A, 

De Parse-knop ve Create 103 veer (51) 5 -x 
vate 94 “ Í oen is | 


De SQL-opdrachten 
van de trigger 


De uitvoer van de trigger 
TRANS _AfterinsertSetAskingPrice 


De uitvoer van de trigger 7 
WATV_InsertTransactionWithWork 


Figuur 10-20 Resultaat van de trigger WATV_InsertTransactionWithWork 


10.7 Concurrency control 


SQL Server 2008 biedt een uitgebreide verzameling functies voor het besturen van 
simultane (concurrent) handelingen. Er zijn veel keuzemogelijkheden en opties 
beschikbaar. Het resulterende gedrag wordt bepaald door de interactie tussen drie 
factoren: het transactie-isolatieniveau, de cursor-concurrency-instelling en locking: 
hints die bij SELECT worden gebruikt. Het locking-gedrag is ook afhankelijk van de 
vraag of de cursor als onderdeel van een transactie wordt verwerkt, of het SELECT- 
statement onderdeel van een cursor is en of update-commando’s onafhankelijk, of 
binnen transacties plaatsvinden. 

In Figuur ro-21 staan de opties voor concurrency control opgesomd. In deze 
paragraaf komen slechts de basisprincipes aan de orde. Lees de SQL Server 
2008-documentatie voor meer informatie. 

In SQL Server plaatsen ontwikkelaars locks niet direct, maar declareert elke 
ontwikkelaar het gewenste concurrency control-gedrag, waarna SQL Server beslist 
waar de locks moeten worden geplaatst. Locks worden toegepast op rijen, pagina's, 
sleutels, indexen, tabellen en zelfs op de gehele database. SQL Server bepaalt welk 
lock-niveau wordt gebruikt en kan tijdens de verwerking een lock-niveau verhogen 
of verlagen. Verder bepaalt SQL Server wanneer de lock moet worden geplaatst en 
weer kan worden verwijderd, afhankelijk van de door de ontwikkelaar gemaakte 
declaraties. 
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Bereik 


Transactie- Verbinding — alle READ UNCOMMITTED 
É zt 5 READ COMMITTED (standaard) 
isolatieniveau transacties REPEATABLE READ 
SNAPSHOT 
SERIALIZABLE 
BE 


READ _ ONLY 
OPTIMISTIG 


Cursor-concurrency | Cursor 


SCROLL LOCK 

Loekingaanwijzingen| SELECT READ COMMITTED 
READ UNCOMMITTED 
REPEATABLE READ 
SERIALIZABLE 
NOLOCK 


HOLDLOCK en andere … 


Figuur 10-21 Opties voor concurrency in SQL Server 2008 


10.7.1 Transactie-isolatieniveau 

Het meest uitgebreide niveau van instellingen is het transactie-isolatieniveau. Zo- 
als in Figuur ro-21 te zien is, zijn er vijf mogelijke transactie-isolatieniveaus. Ze 
worden weergegeven in een volgorde van toenemende beperkingen. Vier van deze 
opties heb je al in hoofdstuk 9 gezien — het zijn de niveaus van de standaard SQL- 
92. Een nieuw niveau, SNAPSHOT, is uniek voor SQL Server. Met het SNAPSHOT- 
transactie-isolatieniveau zijn de gegevens die door een SQL-statement gelezen 
worden, hetzelfde als de gegevens zoals die waren aan het begin van de transactie. 
READ COMMITTED is het standaardisolatieniveau, maar het is mogelijk dirty reads 
te doen door het isolatieniveau op READ UNCOMMITED te zetten. 

Het niveau dat vervolgens de meeste beperkingen oplegt, is REPEATABLE READ, 
waarbij SQL Server locks plaats op alle rijen die worden gelezen. Dit houdt in dat een 
andere gebruiker een gelezen rij pas kan wijzigen of verwijderen als de transactie 
wordt bevestigd of wordt afgebroken. Het opnieuw lezen van de cursor kan echter 
resulteren in phantom reads. 

Het meest beperkende isolatieniveau is SERIALIZABLE. Daarmee plaatst SQL 
Server een serie locks op de rijen die zijn gelezen. Dit zorgt ervoor dat geen gelezen 
gegevens kunnen worden gewijzigd of verwijderd, en dat geen nieuwe rijen in de 
reeks kunnen worden ingevoegd die phantom reads kunnen veroorzaken. Aan dit 
niveau zijn de meeste nadelen verbonden — vandaar dat het alleen moet worden ge- 
bruikt in uiterste noodzaak. 


Een voorbeeld van een TRANSACT-SQL-statement om het isolatieniveau op bij- 
voorbeeld REPEATABLE READ in te stellen, is: 
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SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; 


Dit statement mag overal worden uitgevoerd waar TRANSACT-SQL is toegestaan, 
vóór eventuele andere databaseactiviteiten. 


10.7.2 Cursor-concurrency 

De tweede manier waarop een ontwikkelaar lock-kenmerken kan declareren, is met 
cursor-concurrency. De mogelijkheden daarbij zijn: read_only, optimistic en pessi- 
mistic — wat hier SCROLL _LOCK wordt genoemd. In hoofdstuk g is al beschreven 
dat bij optimistische locking pas een lock kan worden verkregen als de gebruiker de 
gegevens bijwerkt. Als blijkt dat de gegevens sinds de laatste leesactie zijn gewijzigd, 
wordt de update geweigerd. De applicatie moet natuurlijk opgeven wat in een derge- 
lijke situatie moet worden gedaan. 

SCROLL_LOCK is een versie van pessimistische locking. Hiermee wordt een 
update-lock geplaatst in een rij als die rij wordt gelezen. Als de cursor binnen een 
transactie wordt geopend, dan wordt de lock vastgehouden totdat de transactie wordt 
bevestigd of teruggedraaid. Als de cursor buiten een transactie staat, wordt de lock 
ongedaan gemaakt als de volgende rij wordt gelezen. In hoofdstuk g zagen we dat 
een update-lock wel andere update-locks blokkeert, maar geen shared locks. Andere 
verbindingen kunnen de rij dus nog wel lezen met shared locks. 

De standaardinstelling van de cursor-concurrency hangt af van het cursortype 
(zie hoofdstuk 9). De instelling is read-only voor statische en forward only-cursors 
en optimistic voor dynamische en keyset-cursors. 

Cursor-concurrency wordt ingesteld met het commando DECLARE CURSOR. 
We kunnen bijvoorbeeld op de volgende manier een dynamische SCROLL_LOCK- 
cursor declareren voor alle rijen van de tabel TRANS: 


DECLARE MyCursor CURSOR DYNAMIC SCROLL _LOCKS 
FOR 


SELECT 8 
FROM dbo. TRANS; 


10.7.3 Locking-hints 

Het gedrag bij locking kan nader worden beïnvloed door locking-hints in de WITH- 
parameter van de FROM-clausule in SELECT-statements. Figuur 1o-21 geeft een 
overzicht van een aantal locking-hints in SQL Server. De eerste vier overschrijven het 
transactie-isolatieniveau, de volgende twee beïnvloeden het type lock dat is verstrekt. 


Bekijk de volgende statements: 


SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; 
DECLARE MyCursor CURSOR DYNAMIC SCROLL LOCKS 
FOR 

SELECT * 
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FROM dbo.TRANS WITH READUNCOMMITTED NOLOCK; 


Zonder de locking-hints zou de cursor MyCursor een REPEATABLE READ-isolatie 
hebben en update-locks voor alle gelezen rijen verstrekken. De locks zouden actief 
blijven totdat de transactie definitief werd vastgelegd. Door de aanwezigheid van 
de locking-hints wordt het isolatieniveau voor deze cursor READ UNCOMMIT- 
TED en verandert deze cursor door de specificatie met NOLOCK van DYNAMIC in 
READ_ONLY. 

Nog een voorbeeld: 


SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; 
DECLARE MyCursor CURSOR DYNAMIC SCROLL LOCKS 
FOR 

SELECT 

F ROM dbo.TRANS WITH HOLDLOCK; 


In dit voorbeeld hebben de locking-hints als resultaat dat SQL Server update-locks 
voor alle gelezen rijen aanhoudt totdat de transactie definitief wordt gemaakt. Het 
effect is dat het transactie-isolatieniveau voor deze cursor gewijzigd is van REPEATA- 
BLE READ in SERIALIZABLE. 

Over het algemeen wordt de beginnende programmeur afgeraden locking-hints 
te plaatsen. Stel het isolatieniveau en de cursor-concurrency in op defaultwaarden 
voor je transacties en cursors en laat die ongewijzigd. De documentatie van SQL 
Server suggereert nadrukkelijk te vertrouwen op de query-optimalisatie van SQL 
Server, en locking-hints alleen te gebruiken in uiterste noodzaak. 


10.8 SQL Server-beveiliging 


We bespraken het onderwerp beveiliging in hoofdstuk g al in algemene termen. We 
vatten hier samen hoe deze algemene ideeën van toepassing zijn op de beveiliging 
van SQL Server. Het beveiligingsmodel van SQL Server 2008 zie je in Figuur 10-22. 
Zoals gebruikelijk bestaat beveiliging uit authenticatie (inloggen) en autorisatie (het 
verkrijgen van meer of minder rechten). 


In Figuur 10-23 zie je dat we zijn ingelogd in SQL Server (op een computer met 
Windows Server als besturingssysteem en met de naam WSoo3). We zijn ingelogd 
onder WSoo3\Auer en aan deze login is de rol van sysadmin gekoppeld. Dat bete- 
kent dat gebruiker Auer de rechten van een systeembeheerder van SQL Server 2008 
heeft (en dat betekent alle rechten!). Een login van SQL Server kan gebaseerd zijn op 
Windows-authenticatie (aanbevolen door Microsoft), op een specifieke SQL Server- 
login, of op beide. Windows-authenticatie betekent dat de gebruikersnaam die ge- 


bruikt is voor het inloggen bij Windows als gebruikersnaam aan SQL Server wordt 
doorgegeven. 
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Database 
Server-logins 


Database- Schema [Default = dbo] 
gebruiker 


Server-rollen 


Databaserollen 


Server- Schemaobjecten: 


iest EE iT 
Permissies Schemapermissie Ke abellen 
Database- olommen 


permissie Procedures 


Figuur 10-22 SQL Server-beveiliging 


De map Server 
Security 

De map Logins 

De map Server Roles 


Het Server 
Role-object sysadmin 


ee 7 MCD 


Me EN Ven Met Ceb Tom Wrede Court, ven 


Het Server 
Role-dialoogvenster 
voor sysadmin 


Figuur 10-23 Server-logins en Server-rollen 


Een specifieke SQL Server-login is bijvoorbeeld sa, die je in de map Logins ziet in Fi- 
guur 10-23. De afkorting sa staat voor system administrator. Als je die gebruikt zorg 
er dan voor dat er een wachtwoord aan verbonden is. 


Het autorisatiemodel van SQL Server bestaat uit SQL Server principals (principal = 
hoofdrolspeler). Een SQL Server-principal kan een server principal zijn, zoals een 
login of een serverrol, of een database principal, zoals een gebruiker of een database- 
rol. Aan deze principals worden rechten verleend op SQL Server security objects, 
zoals database-schema’s, tabellen en procedures. Het nieuwe begrip is schema. Een 
schema in SQL Server is een container voor SQL Server die een naam heeft. Met 
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andere woorden: SQL-objecten als tabellen en opgeslagen procedures worden bij el- 
kaar gehouden in een container die schema wordt genoemd. Elke SQL server prin- 
cipal kan eigenaar van een schema zijn. Het grote voordeel is dat het eigendom van 
een schema kan worden overgedragen, en dat een database-principal kan worden 
verwijderd zonder verlies van de objecten waarvan de principal eigenaar is. Zie voor 
meer informatie de ontwikkelaarssite van Microsoft msdn.microsoft.com onder de 
zoekterm Owner-Schema Separation. 

Het defaultschema, dat waar een object automatisch aan wordt toegekend, is het 
dbo-schema. In eerdere versies van SQL Server was dbo (database owner) alleen een 
gebruiker, nu is dbo ook een schemanaam. 

Laten we bij wijze van voorbeeld een login maken voor galerie View Ridge. 


Een nieuwe login maken 

1. Vouw de map Security-folder in de Object Explorer uit zodat je de map Logins 

kunt zien. 

2. Klik rechts op de map Logins. 

3. Kies in het snelmenu New Login. 

4. De gegevens voor de nieuwe login zie je in Figuur 10-24. Gebruik die figuur als 

hulpmiddel bij de volgende stappen. 

Typ als Login name de naam VRG-User. 

. Selecteer SQL Server authentication. 

Geef bij Password het wachtwoord VRG-User+password op. 

Typ bij Confirm password opnieuw het wachtwoord VRG-User+password. 

. Haal het vinkje weg bij Enforce password policy om gedwongen wachtwoordbeleid 
uit te schakelen, het verlopen van een wachtwoord uit te schakelen en het afdwin- 
gen van wijzigen van een wachtwoord uit te schakelen. Opmerking: deze stap ver- 
gemakkelijkt het werken in de testfase, doe dit niet in een productie-omgeving. 


Vo oo An 


Mie Ch vee Popo Og Toe Videm Corus, heb 
alten Dd dd 


Ee 


De map Logins 


Het dialoogvenster 
Login — New 


De OK-knop 


5 NT ICRI VET SCEK ERK 
B NT MIDCHIT GTE 

DT ERE 
gem ed 
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ro. Selecteer VRG als de Default-database. Het dialoogvenster Login — New ziet er nu 
uit als in Figuur 10-24. 
im. Klik op OK. 


De nieuwe login is gemaakt. 
10.8.1 Rollen en rechten voor een gebruiker 


We maken nu een nieuwe databasegebruiker aan en koppelen een rol en bijbehorende 
rechten aan deze gebruiker. Figuur 10-25 toont verschillende rollen en hun rechten. 


Vaste databaserol 


Databaserechten _|__DBMS Serverrechten pi 
db_accessadmin 


Rechten: ‚Rechten: 

ALTER ANY USER, CREATE SCHEMA | VIEW ANY DATABASE 
Rechten met GRANT-optie: 
CONNECT Eh 
Rechten: | Rechten: 


BACKUP DATABASE, BACKUP LOG, CHECKPOINT | VIEW ANY DATABASE 


db_backupoperator 


[Zie SQL Server-documentatie 


db_datareader Rechten: Rechten: | 
| SELECT | VIEW ANY DATABASE 
db_datawriter Rechten: E _ |rechten: 
DELETE, INSERT, UPDATE VIEW ANY DATABASE 
db_ddladmin Rechten: Frechten: 


| VIEW ANY DATABASE __ 


db_denydatareader 


db_denydatawriter 


Geen recht op: 
SELECT 


Rechten: 


VIEW ANY DATABASE __ 


| Geen recht op: 


Rechten: 
| VIEW ANY DATABASE 


db_owner Rechten met GRANT-optie: 


fine INSERT, UPDATE 
CONTROL 


Rechten: 


VIEW ANY DATABASE _ 


db_securityadmin Rechten: 

ALTER ANY APPLICATION ROLE, 
ALTER ANY ROLE, 

CREATE SCHEMA, 


VIEW DEFINITION 


documentatie. 


Rechten: 
VIEW ANY DATABASE 


ke 
Opmerking: Zie voor de definitie van de verschillende SQL Serverrechten in deze tabel de SQL Server- 


Figuur 10-25 Vaste databaserollen in SQL Server 2008 


De databasegebruiker die we gaan maken, is gebaseerd op de login die we in de vo- 


rige paragraaf hebben gemaakt. 


Een nieuwe databasegebruiker maken 


1. Vouw het VRG-databaseobject in de Object Explorer uit zodat je de map Security 


ziet. 


„ Vouw de map VRG Security uit zodat je de map Users ziet. 


2 
3. Klik rechts op de map Users. 
4. Kies in het snelmenu New User. 


5. De gegevens voor de nieuwe login zie je in Figuur 10-26. Gebruik die figuur als 


hulpmiddel bij de volgende stappen. 
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6. Typ bij User name de gebruikersnaam VRG-Database-User. 

7. Typ bij Login name de inlognaam VRG-User. Opmerking: Met de browse-knop 
kun je de juiste gebruikersnaam zoeken. 

8. Zet een vinkje bij db_ owner. 


9. Het dialoogvenster ziet er nu uit als in Figuur 10-26. 
ro.Klik op OK. 


De nieuwe gebruiker is aangemaakt. 


[ 


| De map Security re 


nn 


De map Users 


> 5 
| Het dialoogvenster he 


Database User — New 


| De OK-knop mg re nT 


Figuur 10-26 Een databasegebruiker voor VRG maken 


Samenvatting 


SQL Server 2008 kan worden geïnstalleerd op computers met Windows XP, Vista, 
Windows 7, Windows Server 2003 of Windows Server 2008. Er zijn twee manieren 
voor het maken van tabellen, views, indexen en andere databasestructuren. De eerste 
is via het gebruik van grafische ontwerptools, die lijken op die in Microsoft Access. 
Een andere mogelijkheid is SQL-statements te schrijven om de structuren te creêren 
en die vervolgens aan SQL Server door te geven via SQL Server Management Studio. 
SQL Server ondersteunt alle SQL DDL die je in dit boek hebt leren kennen, inclusief 
het sleutelwoord IDENTITY voor het definiëren van surrogaatsleutels. 

SQL Server ondersteunt de taal TRANSACT-SQL, waarin standaard-SQL-state- 
ments worden gecombineerd met programmeergrootheden zoals parameters, varia- 
belen en logische structuren als IF en WHILE. 

SQL Server-databases kunnen worden verwerkt vanuit applicaties die zijn ge- 
schreven in standaardprogrammeertalen zoals Visual Basic.NET, Visual C#.NET of 
Visual C++.NET. Het is ook mogelijk applicatielogica in opgeslagen procedures en 
triggers te plaatsen. Opgeslagen procedures kunnen worden aangeroepen vanuit 
standaardtalen, of vanuit VBScript en JScript in webpagina's. We gebruikten in dit 


407 


DEEL 4 | HULTI-USER-DATABASEVERWERKING 


hoofdstuk de Query Manager van SQL Server voor het aanroepen van opgeslagen 
procedures. Deze techniek mag alleen worden gebruikt tijdens het ontwikkelen en 
testen. 

Het mag om veiligheidsredenen niemand toegestaan worden op een interactie- 
ve manier met een operationele SQL Server-database te werken. Dit hoofdstuk de- 
monstreerde SQL Server-triggers voor het berekenen van defaultwaarden, voor het 
afdwingen van een data constraint, voor het bijwerken van een view en voor het af- 
dwingen van een referential integrity constraint voor een vereiste child. 

Er zijn drie factoren die het concurrency control-gedrag van SQL Server bepa- 
len: het transactie-isolatieniveau, de instelling van de cursor-concurrency en locking- 
hints in de SELECT-clausule. Deze factoren zijn samengevat in Figuur 1o-21. Het 
gedrag verandert ook afhankelijk van waar de acties plaatsvinden: in de context van 
transacties of cursors, of onafhankelijk. Op basis van deze gedragsdeclaraties plaatst 
SQL Server locks namens de ontwikkelaar. Locks kunnen op verschillende granula- 
riteitsniveaus worden geplaatst en kunnen tijdens de verwerkingsfase worden ver- 


hoogd of verlaagd. 


Belangrijke termen 


[* en */ 

ALTER PROCEDURE-statement 

BEGIN... END 

CLOSE CURSOR 

CMD utility 

commentaar in SQL-script 

Common Language Runtime (CLR) 

CREATE PROCEDURE 

database principals 

dbo-schema 

DEALLOCATE CURSOR 

DECLARE CURSOR 

FETCH 

gereserveerd woord 

IF... ELSE 

Integrated Development Environment 
(IDE) 

Microsoft SQL Server 

Microsoft SQL Server 2008 
Management Studio 

Microsoft Windows PowerShell 

OPEN CURSOR 

parameter 

RETURN 
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SCROLL _LOCK 

server principals 

SNAPSHOT transactie-isolatieniveau 

SQL-script 

SQL Server 2008 Express 

SQL Server 2008 Express Advanced 

SQL Server bit data type 

SQL Server functie @ @lIdentity 

SQL Server principal 

SQL Server schema 

SQL Server securable object 

transactie-isolatieniveau 

Transact-SQL (T-SQL) 

Transact-SQL @ @FETCH_STATUS 

Transact-SQL BEGIN TRANSACTION 

Transact-SQL COMMIT 
TRANSACTION 

Transact-SQL CONVERT 

Transact-SQL cursor 

Transact-SQL GETDATE( ) 

Transact-SQL IDENTITY 

Transact-SQL IDENTITY_INSERT 

Transact-SQL PRINT 
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Transact-SQL ROLLBACK Transact-SQL USE { {DatabaseName} } 
TRANSACTION twee mintekens (- -) 

Transact-SQL SET ANSI_NULLS ON variabele 

Transact-SQL SET QUOTED. WHILE 


IDENTIFIER ON 


Oefeningen 


Als je SQL Server 2008 nog niet hebt geïnstalleerd (of anderszins tot je beschikking 
hebt), installeer het dan nu. De vragen 1 tot en met g zijn gebaseerd op een database 
met de naam MEDIA die gebruikt wordt om gegevens te bewaren over foto's. 


1. Maak een database met de naam MEDIA. Gebruik de standaardinstellingen 
voor bestandsgrootten, -namen en -locaties. 

2. Schrijf een SQL-statement voor het maken van een tabel FOTO met kolom- 
men Naam, Omschrijving, DatumGenomen en Bestandsnaam. Ga ervan uit 
dat Naam Char(20), Omschrijving Carchar(20o), DatumGenomen Smalldate 
en Bestandsnaam Char(45) is. Neem verder aan dat Naam en DatumGenomen 
vereist zijn. Gebruik Naam als primaire sleutel en stel de defaultwaarde van 
Omschrijving in op ‘(Geen)’. 

3. Gebruik SQL Server Management Studio om het SQL-statement uit vraag 2 uit 
te voeren om de tabel FOTO in de database MEDIA te creëren. 

4. Schrijf een CREATE TABLE-statement voor het maken van de tabel DIAPRE- 
SENTATIE (PresentatielD, Naam, Omschrijving, Doel) en neem daarbij aan dat 
PresentatielD een surrogate key is. Stel een datatype voor Naam en Omschrij- 
ving in dat volgens jou voldoet. Stel het datatype van Doel in op Char(15) en 
beperk deze tot op de verzameling waarden (“Thuis’, ‘Kantoor’, ‘Familie’, ‘Recre- 
atie’, ‘Sport’, ‘Huisdieren'). Laat het CREATE TABLE-statement uitvoeren. 

5. Maak een tabel PRESENTATIE_FOTO_INT als een intersectietabel van FOTO 
en DIAPRESENTATIE. Maak toepasselijke relaties tussen FOTO en PRESENTA- 
TIE_FOTO_INT en tussen DIAPRESENTATIE en PRESENTATIE_FOTO_ INT. 
Stel een referential integrity constraint in om tegen te gaan dat een DIAPRE- 
SENTATIE-rij wordt verwijderd waaraan een of meer PRESENTATIE_ FOTO. 
INT-rijen zijn gekoppeld. Stel de referential integrity constraint zodanig in dat 
trapsgewijze verwijderingen worden uitgevoerd als een FOTO wordt verwijderd. 

6. Schrijf een SQL-statement om een view PopulairePresentaties te creëren die 
DIAPRESENTATIE.Naam en FOTO.Naam heeft voor alle diapresentaties met 
een Doel van ‘Huis’ of ‘Huisdieren’. Voer dit statement uit in de SQL Server 
Management Studio. 

7. Open de viewontwerptool en ga na of PopulaireVoorstellingen correct is opge- 
steld. Voeg aan deze view FOTO.Omschrijving en Bestandsnaam toe. 

8. Kan het SQL DELETE-statement worden gebruikt met de view PopulaireVoor- 
stellingen? Licht je antwoord toe. 
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9. 


Onder welke omstandigheden kan PopulaireVoorstellingen worden gebruikt 
voor inserts en wijzigingen? 


De vragen ro tot en met 18 gaan over begrippen en concepten die in dit hoofdstuk 
ter sprake zijn gekomen. 


Io. 


II. 
Ia. 


Waarom is in Figuur ro-ro het SELECT-statement dat begint met SELECT @ 
CustomerID noodzakelijk? 

Met welk doel wordt de variabele @Count gebruikt in Figuur 10-10? 

Leg uit hoe je de opgeslagen procedure uit Figuur 1o-1o aanpast als je de klant 
wilt koppelen aan alle kunstenaars die (a) zijn geboren voor 1rgoo of (b) een null- 
waarde als DateOfBirth hebben. 


13. Welke drie hoofdfactoren beïnvloeden het lock-gedrag van SQL Server? 

14. Leg uit waarom de strategie om waarden voor CHECK-constraints in een aparte 
tabel op te slaan beter is. Hoe kun je deze strategie gebruiken om de constraint 
op ARTIST.Nationality te implementeren? 

15. Leg uit waarom de view CustomerlnterestsView in Figuur 10-7 niet bij te werken 
is. Beschrijf de logica van de INSTEAD OF UPDATE-trigger in Figuur 10-16. 

16. Leg uit wat de betekenis is van elk van de transactie-isolatieniveaus die in Figuur 
10-21 onder Opties worden getoond. 

17. Leg uit wat de betekenis is van elk van de cursor-concurrency-instellingen die in 
Figuur 10-21 worden getoond. 

18. Wat is het doel van locking-hints? 

Projectenvragen 


Gebruik de volgende tabellen in je antwoorden op vraag 19 tot en met 21. 


AFDELING (Afdelingsnaam, Budgetcode, Kantoornummer, Telefoon) 
WERKNEMER (Werknemernummer, Achternaam, Voornaam, 
Afdelingsnaam, Telefoon, E-mail) 


Neem aan dat de relatie M-M is. 


19. 


20. 


21. 
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Schrijf een SQL Server-trigger voor het afdwingen van de constraint dat een 
werknemer nooit van afdeling kan veranderen. 

Schrijf een SQL Server-trigger die het mogelijk maakt een afdeling te verwijde- 
ren als deze maar één werknemer heeft. Ken de laatste werknemer toe aan de 
afdeling Personeel. 

Ontwerp een systeem van triggers voor het handhaven van de M-M-relatie. Ge- 
bruik Figuur 10-18 als een voorbeeld, maar neem aan dat afdelingen met maar 
één werknemer kunnen worden verwijderd. Ken de laatste werknemer in een 
afdeling toe aan Personeel. 


DATABASES BEHEREN MET SQL SERVER 2008 


De volgende vraag is gebaseerd op de database van galerie View Ridge zoals die in 
dit hoofdstuk is besproken. 


22. Installeer zo nodig eerst SQL Server 2008. 


À. 
B. 


S: 


mi 


Maak een SQL Server-database met de naam VRG. 

Maak de in Figuur 10-4 getoonde tabellen. Laat alleen de constraint Natio- 
nalityValues weg (in ARTIST). 

Vul de database met gegevens, zie paragraaf 10.3.7. 

Maak alle VRG-views die in hoofdstuk 7 zijn besproken. 

Schrijf een opgeslagen procedure voor het lezen van de tabel ARTIST en 
het weergeven van de kunstenaargegevens met PRINT. 

Schrijf een opgeslagen procedure voor het lezen van de tabellen ARTIST en 
WORK. Je procedure moet de naam van een kunstenaar als invoerparame- 
ter accepteren, dan alle gegevens van deze kunstenaar weergeven, gevolgd 
door alle werken van die kunstenaar die in WORK zijn opgeslagen. 

Schrijf een opgeslagen procedure voor het bijwerken van telefoongegevens 
van klanten. Neem aan dat je opgeslagen procedure LastName, FirstName, 
PriorAreaCode, NewAreaCode, PriorPhoneNumber en NewPhoneNumber 
ontvangt. Je procedure moet eerst zeker stellen dat er maar één klant is met 
de waarden van (LastName, FirstName, PriorAreaCode, PriorPhoneNum- 
ber). Lever een foutmelding en stop als dat niet het geval is. Werk de gege- 
vens van de klant anders bij met de nieuwe telefoongegevens en toon een 
mededeling met het resultaat. 

Maak een tabel met de naam ALLOWED_NATIONALITY met één kolom 
met de naam Nation. Plaats de waarden van alle nationaliteiten die op dit 
moment in de database zitten in deze tabel. Schrijf een trigger die bepaalt 
of een nieuwe of bijgewerkte waarde van Nationality in deze tabel voor- 
komt. Schrijf een foutmelding en draai de insert of wijziging terug als dat 
niet het geval is. Gebruik SQL Server Management Studio om te demon: 
streren dat je trigger werkt. 

Maak een view met alle gegevens van de tabellen WORK en TRANS, be- 
halve de surrogaatsleutels. Schrijf een invoeg-INSTEAD OF-trigger voor 
deze view die een nieuwe rij zal maken in WORK en TRANS. Gebruik SQL 
Server Management Studio om te demonstreren dat je trigger werkt. Hint: 
denk eraan dat je een INSERT-commando kunt uitvoeren op WORK en 
TRANS zonder een waarde voor de surrogaatsleutel op te geven. SQL Ser- 
ver zal deze leveren. 


Marcia’s Chemische Reiniging 


Beantwoord vraag A tot en met M voor Marcia's Chemische Reiniging aan het eind 


van hoofdstuk 7, als je dat niet al hebt gedaan. Gebruik de datatypen van SQL Server 
in je antwoorden. 
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Gebruik SQL Server Management Studio voor het uitvoeren van alle SQL-state- 
ments die je hebt gemaakt als antwoorden op de vragen A tot en met M voor 
Marcia’s Chemische Reiniging aan het eind van hoofdstuk 7. 

Neem aan dat de relatie tussen INVOICE en INVOICE_ITEM M-M is. Ont- 
werp triggers voor het handhaven van deze relatie. Gebruik Figuur 10-18 en 
de bespreking van deze figuur als een voorbeeld, maar neem aan dat Marcia 
het toestaat dat een INVOICE en de gerelateerde INVOICE_ITEM-rijen mogen 
worden verwijderd. Gebruik voor het verwijderen de strategie die in de code van 
Figuur 7-32 en 7-33 wordt getoond. 

Schrijf de triggers die je in vraag B hebt ontworpen en probeer ze uit. 


Importbedrijf Morgan 


Beantwoord vraag A tot en met N voor Importbedrijf Morgan aan het eind van hoofd- 


stuk 7, als je dat niet al hebt gedaan. Gebruik de datatypen van SQL Server in je 
antwoorden. 


À. 
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Gebruik SQL Server Management Studio voor het uitvoeren van alle SQL-state- 
ments die je hebt gemaakt als antwoorden op de vragen A tot en met N voor Im- 
portbedrijf Morgan aan het eind van hoofdstuk 7. 

Neem aan dat de relatie tussen SHIPMENT en SHIPMENT. ITEM M-M is. Ont- 
werp triggers voor het handhaven van deze relatie. Gebruik Figuur 10-18 en de 
bespreking van deze figuur als een voorbeeld, maar neem aan dat Morgan het 
toestaat dat SHIPMENTs en hun gerelateerde SHIPMENT-_ITEM-rijen mogen 
worden verwijderd. Gebruik daar de strategie voor het verwijderen voor die in de 
code van Figuur 7-32 en 7-33 wordt getoond. 

Schrijf de triggers die je in vraag B hebt ontworpen en probeer ze uit. 
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Standaarden voor 
databasetoegang 


De drie hoofdstukken in dit deel gaan over standaarden voor databaseverwerking 
met behulp van applicaties. We beginnen in hoofdstuk 11 met een toelichting van 
standaarden als ODBC, ADO.NET en ASP.NET in Microsofts .NET-framework, en de op 
Java gebaseerde JOBC- en Java Server Pages-technologie. Hoewel sommige van deze 
standaarden niet meer tot de nieuwste behoren, zijn er veel programma’s die er 
nog gebruik van maken. Hoofdstuk 11 gaat verder met een beschrijving van de po- 
pulaire scripttaal PHP om webpagina's te maken met toegang tot de VRG-database. 
Hoofdstuk 12 gaat over een van de belangrijkste ontwikkelingen op het gebied 
van de informatietechnologie: het samenkomen van databaseverwerking en docu- 
mentverwerking. Dit hoofdstuk bevat een inleiding over XML en XML Schema. 


Hoofdstuk 13 gaat over Business Intelligence (BĲ) en datawarehouse- en data- 
mart-databases die dat ondersteunen. 


han Ash a 


Hoofdstuk 11 
De webserveromgeving 


Dit hoofdstuk bespreekt een aantal traditionele standaardinterfaces en moderne mid- 
delen voor het benaderen van databaseservers. ODBC, de Open Database Connectivity- 
standaard, is begin jaren negentig ontwikkeld als een productonafhankelijke interface 
voor het verwerken van relationele en andere gegevens in tabelvorm. Midden jaren 
negentig kondigde Microsoft OLE DB aan, een objectgeoriënteerde interface met inge- 
bouwde dataserverfunctionaliteit. Microsoft ontwikkelde daarna Active Data Objects 
(ADO), een collectie objecten die met OLE DB kan werken en door elke taal kan worden 
gebruikt, inclusief VBScript en JScript. Deze technologie werd gebruikt in Active Server 
Pages (ASP), die de basis vormde voor online databaseapplicaties. 

In 2002 introduceerde Microsoft het .NET Framework met ADO.NET (de opvolger van 
ADO) en ASP.NET (de opvolger van ASP). Op dit moment is het ‚NET Framework de basis 
voor alle applicatieontwikkeling die gebruikmaakt van Microsoft-technologie. 
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Als alternatief voor de technologie van Microsoft ontwikkelde Sun Microsystems het 
Java-platform, met de programmeertaal Java, Java Database Connectivity (JDBC) en 
Java Server Pages (JSP). 

Hoewel de .NET- en Java-technologieën belangrijke ontwikkelplatforms zijn, zijn 
er aanvullende technologieën die door andere bedrijven en opensourceprojecten zijn 
ontwikkeld. We gebruiken in dit hoofdstuk twee van die onafhankelijk ontwikkelde 
tools: de geïntegreerde ontwikkelomgeving (IDE) Eclipse en de PHP-scripttaal. 

Voordat we naar deze standaarden kijken, moeten we ons eerst een voorstelling 
kunnen maken van de dataomgeving van de webserver in databaseapplicaties die 
van internettechnologie gebruikmaken. 


11.1 De dataomgeving van de webserver 


De omgeving waarin online databaseapplicaties zich bevinden, is uitgebreid en ge- 
compliceerd. Uit Figuur 1-1 blijkt dat een gangbare webserver applicaties moet uit- 
voeren waarbij gegevens van de meest uiteenlopende soorten zijn betrokken. 


Relationele databases: 
Oracle, SQL, Server, 
Access, DB2.… 


Niet relationele 
databases 


Browser 


VSAM, ISAM, andere 
bestandsprocessors 


E-mail, andere 
documenttypen 


Browser 


Afbeeldingen, audio, 
andere??? 


Figuur 11-1 Soorten datatypen 


Als ontwikkelaar van webserverapplicaties loop je tegen veel problemen aan als je 
deze gegevens wilt gaan integreren. Je moet mogelijk verbinding maken met een 
Oracle-database, een DB2-mainframedatabase, een niet-relationele database zoals 
IMS, of gebruikmaken van systemen als VSAM en ISAM, e-maildirectory’s, enzo- 
voort. Elk van deze producten beschikt over een andere interface waarmee de ont- 
wikkelaar bekend moet zijn. 
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Er zijn verscheidene standaardinterfaces ontwikkeld voor het benaderen van databa- 
seservers. leder DBMS-product heeft een application programmer interface (API). 
Een API is een verzameling van objecten, methoden en eigenschappen om de func- 
ties van een DBMS uit te voeren vanuit programmacode. Helaas heeft elk DBMS-pro- 
duct zijn eigen API, die onderling nogal verschillend kunnen zijn. Om te voorkomen 
dat programmeurs zich veel verschillende interfaces eigen moeten maken, heeft de 
computerindustrie standaarden ontwikkeld voor databasetoegang. 

ODBC, de Open Database Connectivity-standaard, is begin jaren negentig ont- 
wikkeld als een productonafhankelijke interface voor het verwerken van relationele 
en andere gegevens in tabelvorm. Midden jaren negentig kondigde Microsoft OLE 
DB aan, een objectgeoriënteerde interface met ingebouwde dataserverfunctionali- 
teit. OLE DB is niet alleen ontworpen voor relationele databases, maar ook voor het 
benaderen van diverse andere soorten gegevens. OLE DB is een Component Object 
Model (COM)-interface, waardoor het makkelijk gebruikt kan worden door C-, C#- 
en Java-programmeurs. Het is echter minder toegankelijk vanuit Visual Basic (VB) 
en scripttalen. Microsoft ontwikkelde om die reden Active Data Objects (ADO), een 
collectie objecten die met OLE DB kan werken en door elke taal kan worden ge- 
bruikt, inclusief Visual Basic, VBScript en JScript. 

ADO is nu opgevolgd door ADO.NET, wat een verbeterde versie is van ADO en 
onderdeel van het .NET Framework. 

De ADO-technologie wordt gebruikt in Active Server Pages (ASP) om online da- 
tabaseapplicaties te maken. ASP is een combinatie van Hypertext Markup Language 
(HTML) en VBScript of JScript waarmee je gegevens uit een database kunt lezen 
en schrijven, en via publieke en private netwerken kunt versturen, daarbij gebruik- 
makend van internetprotocols. ASP draait op Microsofts webserverproduct Internet 
Information Services (IIS). Tegelijk met ADO.NET introduceerde Microsoft ASP. 
NET, de opvolger van ASP en de belangrijkste technologie voor het maken van web- 
pagina’s in het .NET Framework. 

Er zijn natuurlijk andere standaarden naast die van Microsoft. De belangrijkste 
alternatieven voor ADO.NET zijn gebaseerd op of gerelateerd aan het door Sun Mi- 
crosystems ontwikkelde Java-platform, met de programmeertaal Java, Java Database 
Connectivity (JDBC), Java Data Objects (JDO) en Java Server Pages (JSP). 

Java Server Pages is een combinatie van HTML en Java, die hetzelfde resultaat 
bereikt als ASP.NET door de pagina’s te vertalen in Java-servlets. Met JSP kun je een 
databaseverbinding maken via JDBC. JSP wordt vaak gebruikt op de opensource- 
webserver Apache. 

Het belangrijkste kenmerk van de Java-gerelateerde technologie is dat je Java als 
programmeertaal moet gebruiken. Je kunt zelfs geen JavaScript gebruiken, de enigs- 
zins aan Java verwante scripttaal. 

Hoewel het .NET Framework en het Java-platform twee grote spelers zijn op het 
gebied van de ontwikkeling van webapplicaties, zijn er ook andere opties. Een van 
die opties is PHP, een opensourceprogrammeertaal voor webpagina's. PHP samen 
met de Apache-webserver en het MySQL DBMS vormt ook een favoriete combinatie 
van webontwikkelaars. Deze combinatie heet AMP (Apache, MySQL, PHP). Als het 
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onder Linux draait heet het LAMP, onder Windows WAMP. Omdat PHP met alle 
DBMS-producten werkt, gebruiken we het in dit boek. Andere mogelijkheden zijn 
de talen Perl of Python (die beide de P in AMP, LAMP of WAMP kunnen zijn) en de 
taal Ruby met het webontwikkelframework Ruby on Rails (RoR). 

In een webgebaseerde databaseomgeving heeft het systeem een two-tier (twee la- 
gen) architectuur als de webserver en het DBMS op dezelfde computer draaien. Eén 
tier wordt gevormd door de browsers, en eén door de computer met de webserver 
en het DBMS. De webserver en het DBMS kunnen ook op verschillende computers 
draaien, het systeem heeft dan een three-tier architectuur. Applicaties die grote pres- 
taties moeten leveren, gebruiken mogelijk verschillende computers met webservers, 
en in sommige systemen draait het DBMS ook op verschillende computers. In dit 
laatste geval, als de DBMS-computers gebruikmaken van dezelfde database, heet het 
systeem wel een gedistribueerde database (distributed database). 


11.2 De ODBC-standaard 


De ODBC-standaard is ontwikkeld om het hoofd te bieden aan de problemen met 
betrekking tot gegevenstoegang bij relationele databases en datasources die in tabel- 
vorm staan, zoals spreadsheets. In Figuur 11-2 is te zien dat ODBC een interface is 
tussen de webserver (of een andere databasegebruiker) en de databaseserver. Het 
bestaat uit een collectie standaarden aan de hand waarvan SQL-statements kunnen 
worden verstrekt en resultaten en foutmeldingen worden gegenereerd. Ontwikke- 
laars kunnen het DBMS desgewenst aanroepen via DBMS-interfaces (soms doen ze 
dat om de performance te verbeteren), maar kunnen ook ODBC gebruiken. 
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Figuur 11-2 De rol van ODBC 
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DE WEBSERVEROMGEVING 


De ODBC-standaard is een interface waarmee een applicatie databases en gegevens 
in tabelvorm op een DBMS-onafhankelijke wijze kan benaderen en verwerken. Dit 
betekent bijvoorbeeld dat een applicatie die gebruikmaakt van ODBC een Oracle- 
database, een SQL Server-database, een spreadsheet of elke andere database kan 
verwerken die in overeenstemming is met ODBC zonder iets in het programma te 
hoeven veranderen. Het doel is het een ontwikkelaar mogelijk te maken één applica- 
tie te schrijven die databases kan aanspreken die door verschillende DBMS-produc- 
ten worden ondersteund, zonder dat daartoe iets moet worden veranderd of opnieuw 
gecompileerd. 

ODBC is ontwikkeld door een commissie die bestond uit deskundigen uit de X/ 
Open- en SQL Access Group-commissies. Er werden verscheidene van dergelijke 
standaarden voorgesteld, maar ODBC kwam als winnaar uit de bus, met name om- 
dat het is geïmplementeerd door Microsoft en omdat het een belangrijk onderdeel 
van Windows vormt. Microsoft was oorspronkelijk geïnteresseerd in het ondersteu- 
nen van een dergelijke standaard omdat men wilde dat producten zoals Microsoft 
Excel toegang tot databasegegevens konden krijgen vanuit diverse DBMS-producten, 
zonder dat die gegevens opnieuw gecompileerd moesten worden. De belangen van 
Microsoft zijn natuurlijk veranderd sinds de invoering van OLE DB en ADO.NET. 


11.2.1 De architectuur van ODBC 

Figuur 11-3 geeft een overzicht van de componenten van de standaard ODBC. De ap- 
plicatie, de driver-manager en DBMS-drivers staan alle op de webservercomputer. De 
drivers sturen verzoeken naar datasources, die op de databaseserver staan. Volgens 
de standaard bestaat een datasource uit de database en het bijbehorende DBMS, 
besturingssysteem en netwerkplatform. Een ODBC-datasource kan een relationele 
database zijn, maar ook een fileserver zoals BTrieve en zelfs een spreadsheet. 


Applicatieserver Datasources 


DBMS-driver1 


Driver- 
manager 


Applicatie DBMS-driver2 f 


DBMS-driver3 


De applicatie kan een database van elk van de 
drie DBMS-producten verwerken. 


Figuur 11-3 De architectuur van ODBC 
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De applicatie dient verzoeken in om een verbinding met een datasource tot stand te 
brengen, om SQL-statements uit te voeren en resultaten te ontvangen, om fouten te 
verwerken, en om transacties te starten, vast te leggen en terug te draaien. ODBC 
voorziet in een standaardmiddel voor al deze verzoeken en het definieert een stan- 
daardcollectie foutcodes en foutmeldingen. 

De ODBC-driver-manager fungeert als intermediair tussen de applicatie en de 
DBMS-drivers. Als de applicatie om een verbinding vraagt, bepaalt de driver-mana- 
ger welk DBMS een bepaalde ODBC-datasource verwerkt en laadt die driver dan in 
het geheugen (als dat nog niet is gebeurd). De driver-manager verwerkt ook bepaalde 
initialisatieverzoeken en valideert de indeling en volgorde van ODBC-aanvragen die 
hij van de applicatie ontvangt. De driver-manager wordt in het geval van Windows 
door Microsoft geleverd. 

Een ODBC-driver verwerkt ODBC-verzoeken en stuurt specifieke SQL-state- 
ments naar een bepaald type datasource. Voor elk type datasource is een ander driver. 
Zo zijn er drivers voor SQL Server, voor Oracle, voor MySQL, voor Access en voor 
alle andere producten waarvan de leveranciers hebben gekozen deel te nemen aan 
de ODBC-standaard. Drivers worden geleverd door DBMS-leveranciers en door on- 
afhankelijke softwarebedrijven. 

Het is de verantwoordelijkheid van de driver ervoor te zorgen dat standaard. 
ODBC-opdrachten correct worden uitgevoerd. In bepaalde gevallen, als de datasour- 
ce zelf niet voldoet aan de SQL-standaard moet de driver misschien een aanzienlijk 
aantal bewerkingen uitvoeren ter compensatie van de beperkte mogelijkheden van 
de datasource. In andere gevallen, waar de datasource SQL volledig ondersteunt, 
hoeft de driver het verzoek alleen maar door te geven zodat de datasource het kan 
verwerken. De driver zorgt verder voor de conversie van foutcodes en -meldingen 
van de datasource naar standaard-ODBC-codes en -meldingen. 

ODBC kent twee typen drivers: single-tier en multi-tier. Een single-tier driver 
verwerkt zowel ODBC-aanroepen als SQL-statements. In Figuur 11-4(a) is een voor- 
beeld te zien van een single-tier driver. In dit voorbeeld worden de gegevens op: 
geslagen in Xbase-bestanden (de indeling die wordt gehanteerd door onder meer 
FoxPro en dBase). Omdat Xbase-file-managers geen SQL verwerken, moet de driver 
het SQL-verzoek vertalen naar Xbase-bestandsmanipulaties en de resultaten omzet- 
ten in SQL-vorm. 

Een multi-tier driver verwerkt ODBC-aanroepen, maar geeft de SQL-verzoeken 
rechtstreeks door aan de databaseserver. Soms wordt daarbij de indeling van het ver- 
zoek aangepast aan het dialect van een bepaalde datasource, maar de SQL zelf wordt 
nooit verwerkt. Een voorbeeld van het gebruik van een multi-tier driver is afgebeeld 
in Figuur 11-4(b). 
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Figuur 11-4 De typen ODBC-drivers: (a) single-tier ODBCEdriver en (b) multi-tier ODBC-driver 


11.2.2 Conformiteitsniveaus 

De makers van de ODBC-standaard stonden voor een dilemma. Als ze voor een 
eenvoudige standaard kozen, zouden veel leveranciers daaraan kunnen voldoen. Er 
zou dan echter flink worden ingeboet aan de kracht van ODBC en SQL. Als ze de 
standaard heel uitgebreid maakten, zou daarentegen slechts een handvol leveran- 
ciers met een product voor de dag kunnen komen dat volledig met deze standaard 
in overeenstemming zou zijn, waardoor het hele idee van een standaard vrij zinloos 
zou worden. Er werden twee verschillende conformiteitstypen voor de standaard ge- 
definieerd: ODBC-conformiteit en SQL-conformiteit. 


11.2.3 ODBC-conformiteitsniveau 

ODBC-conformiteitsniveaus hebben betrekking op de functies en mogelijkheden 
die beschikbaar zijn via de API van de driver. De API van de driver is een verzame- 
ling functies die de applicatie kan aanroepen om bepaalde zaken gedaan te krijgen. 


In Figuur 1-5 is een overzicht weergegeven van de drie ODBC-conformiteitsniveaus 
volgens de standaard. In de praktijk blijken bijna alle drivers minstens API-confor- 
miteitsniveau 1 te bieden. 

Een applicatie kan een driver aanroepen om vast te stellen welk ODBC-conformi- 
teitsniveau deze biedt. Als de applicatie om een conformiteitsniveau vraagt dat niet 
aanwezig is, kan ze de sessie op een nette manier afsluiten en bijbehorende mel- 
dingen voor de gebruiker genereren. De applicatie kan ook zo worden geschreven 
dat, indien mogelijk, conformiteitsfuncties van een hoog niveau worden gebruikt — 
mocht dat niet lukken dan wordt naar een alternatieve oplossing gezocht. 
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APl-basisniveau 

e Verbinding maken met datasources 

e SQL-statements voorbereiden en uitvoeren 

e Gegevens van een resultaatcollectie ontvangen 
e Transacties vastleggen of terugdraaien 

e Foutinformatie opvragen 


APl-niveau 1 
e API-basisniveau 
e Verbinding maken met datasources met informatie specifiek voor driver 


e Gedeeltelijke resultaten verzenden en ontvangen 
e Catalogusinformatie opvragen 
e Informatie opvragen over opties, mogelijkheden en functies van driver 


APl-niveau 2 


e API-basisniveau en -niveau 1 
e Mogelijke verbindingen en datasources browsen 
e Oorspronkelijke SQL-vorm opvragen 

e Een vertaalbibliotheek aanroepen 

e Een schuifbare cursor verwerken 


Figuur 11-5 Overzicht van ODBC-conformiteitsniveaus 


Zo moeten drivers van API-niveau 2 voorzien in een schuifbare cursor. Er kan een 
applicatie worden geschreven waarin cursors worden gebruikt als die beschikbaar 
zijn — als die functie ontbreekt, worden met behulp van erg strikte WHERE:state- 
ments de benodigde gegevens geselecteerd. Hierdoor worden slechts enkele rijen 
per keer teruggegeven aan de applicatie, die vervolgens worden verwerkt met een ei- 
gen cursor. De prestaties zullen in het tweede geval minder zijn, maar de applicatie 
is in ieder geval succesvol uit te voeren. 


11.2.4 SQL-conformiteitsniveau 

In de SQL-conformiteitsniveaus wordt opgegeven welke SQL-statements, expressies 
en -datatypen een driver kan verwerken. Er bestaan drie SQL-conformiteitsniveaus, 
zoals in het overzicht in Figuur 11-6 is te zien. De mogelijkheden van de minimale 
SQL-grammatica zijn erg beperkt en de meeste drivers ondersteunen minstens de 
basis-SQL-grammatica. 


Net als met ODBC-conformiteitsniveaus kan een applicatie de driver aanroepen om 


te bepalen welk SQL-conformiteitsniveau wordt ondersteund. Met die informatie 
kan de applicatie vervolgens vaststellen welke SQL-statements kunnen worden ver- 
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Minimale SQL-grammatica 
e CREATE TABLE, DROP TABLE 
e Eenvoudige SELECT (zonder subquery's) 


e INSERT, UPDATE, DELETE 
e Eenvoudige expressies (A > B + C) 
e Datatypen CHAR, VARCHAR, LONGVARCHAR 


Basis-SQL-grammatica 
gis SQL-grammatica 
e ALTER TABLE, CREATE INDEX, DROP INDEX 
e CREATE VIEW, DROP VIEW 
e GRANT, REVOKE 
e Volledige SELECT (inclusief subquery's) 
e Rekenkundige functies zoals SUM, COUNT, MAX, MIN, AVG || 
 Datatypen DECIMAL, NUMERIC, SMALLINT, INTEGER, | 
REAL, FLOAT, DOUBLE PRECISION | 


Uitgebreide SQL-grammatica 

e Basis-SQL-grammatica 

e Outer joins 

e UPDATE en DELETE met cursorposities 

e Scalaire functies zoals SUBSTRING, ABS 

e Constante waarden voor date, time en timestamp 
e SQL-groepstatements 

e Opgeslagen procedures 


Figuur 11-6 Overzicht van SQL-conformiteitsniveaus 


strekt. Indien nodig kan de applicatie de sessie beëindigen of alternatieve, minder 
krachtige middelen gebruiken om de gegevens op te halen. 


11.2.5 Een Data Source Name opstellen 

Een datasource (gegevensbron) is een ODBC-datastructuur waarmee een database 

en het bijbehorende DBMS worden geïdentificeerd. Er zijn drie typen gegevensbron- 

nen: bestands-, systeem- en gebruikersgegevensbronnen.: 

» Een bestandsgegevensbron is een bestand dat door verschillende databasegebrui- 
kers kan worden gedeeld. De enige vereiste is dat de gebruikers over dezelfde 
DBMS-driver beschikken en over dezelfde privileges voor het benaderen van de 
database. De bestandsdatasource kan worden gemaild of op andere wijze onder 
mogelijke gebruikers worden gedistribueerd. 

* Een systeemgegevensbron staat lokaal op één computer. Het besturingssysteem 
en elke gebruiker op dat systeem (met de juiste privileges) kunnen van een sys- 
teemdatasource gebruikmaken. 
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- Een gebruikersgegevensbron is alleen beschikbaar voor de gebruiker die hem 
heeft gecreëerd. 


In het algemeen kan men bij webapplicaties het beste een systeemdatasource op de 
webserver plaatsen. Gebruikers kunnen dan met een browser de webserver benade- 
ren, die op zijn beurt een systeemdatasource gebruikt om een verbinding tot stand 
te brengen met het DBMS en de database. 

We hebben een systeemgegevensbron nodig voor de database van galerie View 
Ridge zodat we die in een webapplicatie kunnen gebruiken. Om een systeem- 
gegevensbron in een Windows-omgeving te maken, gebruik je de ODBC Data Sour- 
ce Administrator'. Hieronder staan de stappen beschreven die je moet doen, tussen 
haakjes en cursief de termen in de Engelse versie van Windows. 


Openen van ODBC Gegevensbronbeheer (ODBC Data Source Administrator) in 
Windows XP of Vista 


r. Klik op Start | Configuratiescherm (Control Panel). 

2. Schakel zo nodig naar Klassieke weergave (Classic View). 

3. Dubbelklik op Systeembeheer (Administrative Tools). 

4. Dubbelklik op Gegevensbronnen (ODBC) (Data Sources (ODBC)). 


We kunnen nu in het venster van ODBC-gegevensbronbeheer een systeemgegevens- 
bron maken met de naam VRG voor het gebruik met SQL Server 2008. 


Het maken van de gegevensbron VRG 


1. Klik in het venster van ODBC-gegevensbronbeheer op de tab Systeem-DSN 
(System DSN). 


2. Klik op Toevoegen (Add). 


3. Kies uit de lijst SQL Server Native Client ro, zie Figuur 11-7. 
4. Klik op Voltooien (Finish). 


Het venster Create a New Data Source to SQL Server verschijnt, zie Figuur 11-8. 


1. Vul in dit venster de gegevens in zoals je die ziet in Figuur 11-8. 
2. Klik op Finish om het venster te sluiten. 


Je krijgt een overzicht te zien van de gemaakte gegevensbron. We zullen deze later 
in dit hoofdstuk gebruiken. 


1 Houd er rekening mee dat er twee verschillende ODBC Data Source Administrator-programma's 
zijn: een voor 32 bits- en een voor 64 bits-applicaties. Het programma dat wij hier gebruikt hebben, 
is de 64 bits-versie. 

Als je bijvoorbeeld onder een 64 bits-versie van Vista een 32 bits-DBMS draait, zoals de 32 bits-versie 
van SQL Server Express, dan moet je de 32 bits-versie van ODBC Data Source Administrator gebrui- 
ken. Dit is het bestand odbcad32.exe in de map C:\Windows\sysWOWG4. 
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Kies System DSN Ĳ n en xd 
en klik op Add jen ser DSN System DSN | Fie DSN | Drivers | Tracing | Connection Pong | About | 


5 


De MySQL ODBC j System Data Sources 
5.1 Driver \ 


Kies SQL Server 
Native Client 10.0 


Klik op Finish 


Microsoft Text Dnver (bt, “ csv) 
Microsoft Text-Treiber (“ bd; “ csv) 
Microsoft Visual FoxPro Onver 
Wierosoft Visual FoxPro-Treber 
MySQL ODBC 5.1 Dnver 

SQL Server 

SQL Server Native Client 10.0 


Í: Data Source 2Ixl 
Typ de naam van de E $ 
EE VRG n User DSN System DSN | Fie DSN | Orvers | Tracing | Connection Poolng | About | | 


An 


Crete a New Data Source to SQL 


Typ een omschrijving 


Thus wizard wil help you create an ODBC data source that you can use to 
Kies de SQL-server connect to SQL Server 
uit de keuzelijst; als 


de lijst leeg is, typ dan Í 


de naam van de Name*[vRG 
server zelf { ; 


| How do yoùrwant to describe the data source? 
| Descnption’ [VRG Database on SQL Server 2008 


Which SQL Server do you want to connect to? 


ä 
| Server. [TEC +] 


(mn | vo | Cet | to | 


Figuur 11-8 Het dialoogvenster Create a New Data Source to SQL Server 
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11.3 OLE DB 


ODBC is een enorm succes gebleken en diverse databaseontwikkeltaken zijn er aan- 
zienlijk door vereenvoudigd. Er zijn echter een paar nadelen — en in het bijzonder 
een belangrijk nadeel waaraan Microsoft tegemoetkomt met OLE DB. In Figuur 1-9 
zie je de relaties tussen OLE DB, ODBC en andere datatypen. 


Relationele 
databases: Oracle, 
SQL Server, 
Access, DB2,... 


Niet-relationele 
databases 


VSAM, ISAM, 
andere 


| bestandsprocessors 
Webserver 


E-mail, andere 
documenttypen 


Afbeeldingen, 
audio, andere 222? 


Figuur 11-9 De rol van OLE DB 


OLE DB is een van de bases voor het benaderen van gegevens in de Microsoft-wereld. 
Vandaar dat het belangrijk is dat je enige kennis hebt van deze standaard, zelfs als 
je alleen met de ADO.NET-interfaces werkt die daarbovenop liggen, omdat OLE DB 
zorgt voor de gegevensvoorziening aan ADO.NET. In deze paragraaf tonen we be- 
langrijke OLE DB-concepten. We gebruiken ze om een aantal belangrijke objectge- 
oriënteerde concepten te introduceren. 

OLE DB voorziet in een objectgeoriënteerde interface voor bijna elk type gegevens. 
DBMS-leveranciers kunnen delen van hun eigen bibliotheken in OLE DB-objecten 
inbedden, waardoor de functionaliteit van hun product via deze interface beschik- 
baar komt. OLE DB is ook te gebruiken als een interface voor ODBC-datasources. 
OLE DB is verder ontwikkeld ter ondersteuning van het verwerken van niet-relatio- 
nele gegevens. 

OLE DB is een implementatie van de Microsoft-objectstandaard Object Linking 
and Embedding (OLE). OLE DB-objecten zijn COM-objecten die alle vereiste in- 
terfaces voor zulke objecten ondersteunen. Feitelijk deelt OLE DB de functies en 
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mogelijkheden van een DBMS op in COM-objecten. Er kunnen objecten zijn die 
querybewerkingen uitvoeren, andere die wijzigingen uitvoeren of tabellen, indexen 
en views maken, en weer andere die transactiebeheer uitvoeren, zoals optimistische 
locking. 

Hiermee wordt een groot nadeel van ODBC uit de weg geruimd. Met ODBC 
moest een leverancier voor bijna alle DBMS-functies en -mogelijkheden een ODBC- 
driver ontwikkelen om überhaupt aan ODBC deel te kunnen nemen. Dit is enorm 
veel werk en vereist een aanzienlijke investering. Met OLE DB kan een DBMS-leve- 
rancier echter delen van zijn product implementeren. Men kan bijvoorbeeld alleen 
de queryprocessor implementeren, deelnemen aan OLE DB en op die manier toe- 
gankelijk zijn voor klanten die met ADO.NET werken. In een later stadium kan die 
leverancier meer objecten en interfaces toevoegen om de OLE DB-functionaliteit van 
zijn producten uit te breiden. 

Wij gaan er in dit boek niet van uit dat je een objectgeoriënteerde programmeur 
bent, dus moeten we eerst enkele nieuwe begrippen introduceren. Je moet specifiek 
weten wat met de volgende termen wordt bedoeld: abstracties, methoden, eigen- 
schappen en collecties. Een abstractie is een generalisatie van iets. ODBC-interfaces 
zijn abstracties van toegangsmethoden van een DBMS. Als we iets abstraheren, ver- 
liezen we details maar krijgen we de mogelijkheid om te werken met een breder as- 
sortiment typen. 

Een recordset is een voorbeeld van een abstractie van een relatie. In deze ab- 
stractie wordt een recordset gedefinieerd met bepaalde kenmerken die voor alle 
recordsets gelden. Elke recordset heeft bijvoorbeeld een reeks kolommen die in deze 
abstractie Fields worden genoemd. We willen met abstractie alles vastleggen wat be- 
langrijk is en details weglaten die de gebruikers van de abstractie niet nodig hebben. 
Oracle-relaties kunnen dus een bepaald kenmerk hebben dat niet in een recordset is 
vertegenwoordigd — hetzelfde kan gelden voor relaties in SQL Server, DB2 en andere 
DBMS-producten. Deze unieke kenmerken gaan verloren in de abstractie, maar als 
de abstractie goed is, is dat geen probleem. 

Een niveau hoger vinden we rowsets, de OLE DB-abstractie van recordsets. De 
reden dat OLE DB een andere abstractie definieert, is dat OLE DB datasources aan- 
spreekt die geen tabellen zijn, maar wel bepaalde kenmerken van tabellen hebben. 
De e-mailadressen in je adressenbestand zijn niet hetzelfde als een relatie, maar ze 
hebben wel enkele kenmerken gemeen met relaties. Elk adres is een semantisch ge- 
koppelde groep met data-elementen. Het is net als bij rijen van een tabel logisch om 
naar het eerste element te gaan, dan naar het volgende, enzovoort. Maar in tegen- 
stelling tot relaties zijn ze niet allemaal van hetzelfde type — sommige adressen zijn 
voor personen en andere voor mailinglijsten. Dus elke bewerking op een recordset 
waarbij wordt vereist dat alles in de recordset van hetzelfde type is, kan niet op een 
rowset worden toegepast. 

Van boven naar beneden definieert OLE DB een verzameling gegevens- en ge- 
dragseigenschappen voor rowsets. Elke rowset heeft die eigenschappen. Verder 
definieert OLE DB een recordset als een subtype van een rowset. Recordsets hebben 
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alle eigenschappen die rowsets hebben, plus enkele die unieke kenmerken zijn van 
recordsets. 

Abstractie wordt veel gebruikt en is erg handig. Men heeft het wel over abstracties 
van transactiebeheer, abstracties van query’s of abstracties van interfaces. Dit bete- 
kent simpelweg dat bepaalde kenmerken van een verzameling elementen op forme- 
le wijze als een type worden gedefinieerd. 

In objectgeoriënteerd programmeren is een object een abstractie die wordt gede- 
finieerd door haar eigenschappen (gegevens) en methoden (gedrag). Een recordset- 
object heeft bijvoorbeeld een AllowEdits-eigenschap, een RecordsetType-eigenschap 
en een EOF-eigenschap. Deze eigenschappen vertegenwoordigen kenmerken van de 
recordsetabstractie. Een object beschikt ook over acties die het kan uitvoeren en die 
methoden worden genoemd. Een recordset heeft methoden zoals Open, MoveFirst, 
MoveNext en Close. 

Strikt gesproken heet een objectabstractie een objectklasse of kortweg klasse. Een 
instantie van een objectklasse, zoals een bepaalde recordset, heet een object. Alle ob- 
jecten van een klasse hebben dezelfde methoden en eigenschappen, maar de waar- 
den van die eigenschappen variëren per object. 

Het laatste begrip dat we moeten uitleggen, is collectie. Een collectie is een object 
dat een groep andere objecten bevat. Een recordset bevat een collectie andere ob- 
jecten, Fields genaamd. De collectie heeft eigenschappen en methoden. Een van de 
eigenschappen van alle collecties is Count, het aantal objecten in de collectie. Dus re- 
cordset. Fields.Count is het aantal velden in de collectie. In OLE DB hebben collecties 
als naam het meervoud van de objecten die erin zitten. Er is dus een Fields-collectie 
met Field-objecten, een Errors-collectie met Error-objecten, een Parameters-collectie 
met Parameters, enzovoort. Een belangrijke methode van een collectie is een iterator 
— dit is een methode om de elementen in de collectie te doorlopen of te identificeren. 

Als het je een beetje duizelt van al deze begrippen, kunnen we je geruststellen. 
Verderop in dit hoofdstuk vind je praktische toepassingen van deze concepten. 


11.3.1 Doelstellingen van OLE DB 

De belangrijkste doelstellingen van OLE DB staan opgesomd in Figuur 11-10. De eer- 
ste is, zoals we al vermeldden, het opdelen van DBMS-functionaliteit en -diensten. 
Deze opdeling betekent een grote flexibiliteit voor gegevensconsumenten of data 
consumers (gebruikers van OLE DB-functionaliteit) en gegevensleveranciers of data 
providers (leveranciers van producten die OLE DB-functionaliteit aanleveren). Gege- 
vensconsumenten nemen alleen de objecten en functionaliteit die zij nodig hebben 
— een draadloos apparaat voor het lezen van een database ondersteunt misschien een 
minimum aan functionaliteit. In tegenstelling tot ODBC hoeven gegevensleveran- 
ciers slechts een deel van de DBMS-functionaliteit te implementeren. Deze opdeling 
houdt tevens in dat gegevensleveranciers voorzieningen in verscheidene interfaces 
kunnen afleveren. 


Dit laatste punt vraagt om wat meer uitleg. Een objectinterface is een pakket objecten. 
Een interface wordt gespecificeerd door een collectie objecten en de eigenschappen 
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e Objectinterfaces creëren voor delen van DBMS-functionaliteit 
- Query 
- Wijziging 
- Transactiebeheer 
- Enzovoort 
e Flexibiliteit verbeteren 
- Gegevensconsumenten toestaan alleen de objecten te 
gebruiken die ze nodig hebben 
- Gegevensleveranciers toestaan delen van DBMS-functio- 
naliteit te laten zien 
- Leveranciers kunnen functionaliteit in verscheidene 
interfaces afleveren 
- Interfaces zijn gestandaardiseerd en uitbreidbaar 
e Objectinterface via elk datatype 
- Relationele database 
- ODBC of systeemeigen 
- Niet-relationele database 
- VSAM en andere bestanden 
- E-mail 
- Overige 
e Gegevens hoeven niet te worden geconverteerd of te worden verplaatst 


Figuur 11-10 De doelstellingen van OLE DB 


en methoden die zij laten zien. Een object hoeft niet al zijn eigenschappen en 
methoden in een bepaalde interface te laten zien. Een recordsetobject laat in een 
query-interface alleen zijn leesmethoden zien, maar laat zijn creëer-, wijzig- en ver- 
wijdermethoden zien in een modificatie-interface. 

Op welke wijze het object de interface of de implementatie ondersteunt, is voor 
de gebruiker volledig verborgen. De ontwikkelaars van een object kunnen zelfs op 
elk gewenst moment de implementatie aanpassen — niemand zal het merken. Maar 
ze mogen in geen geval de interface wijzigen teneinde terechte klachten van de ge- 
bruikers te voorkomen. 

OLE DB definieert gestandaardiseerde interfaces. Gegevensleveranciers zijn 
echter volledig vrij om interfaces aan de basisstandaarden toe te voegen. Die uit- 
breidbaarheid is essentieel voor de volgende doelstelling: het leveren van een object- 
interface voor elk datatype. Relationele databases kunnen worden verwerkt via OLE 
DB-objecten die gebruikmaken van ODBC of van de systeemeigen drivers van het 
DBMS. OLE DB bevat ook ondersteuning voor de andere typen. 
uden vorm ie converteren en van de ene maar de andere datasource te verplaat. 
sen. De webserver in Figuur 11-9 kan OLE DB inzetten om gegevens in elke wille- 
keurige indeling te verwerken, op de plek waar de gegevens staan. Dit betekent dat 
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transacties zich kunnen uitstrekken over verscheidene datasources en over verschil- 
lende computers kunnen worden verspreid. De OLE DB-voorziening daarvoor is de 
Microsoft Transaction Manager (MTS), maar het behandelen daarvan valt buiten het 
kader van dit hoofdstuk. 


11.3.2 OLE DB terminologie 

In Figuur 1-11 is te zien dat OLE DB twee typen gegevensleveranciers kent. Tabulai- 
re gegevensleveranciers presenteren hun gegevens via rowsets. Voorbeelden daarvan 
zijn DBMS-producten, spreadsheets en ISAM-bestandsprocessors, maar ook andere 
datatypen zoals e-mail kunnen in rowsets worden gepresenteerd. Tabulaire gege- 
vensleveranciers brengen gegevens van een bepaald type in de wereld van OLE DB. 


e Tabulaire gegevensleverancier 

e Toont gegevens via rowsets 

e Voorbeelden: DBMS, spreadsheets, ISAM's, e-mail 
e Serviceprovider 


e Transformeert gegevens via OLE DB-interfaces 
e Zowel consument als leverancier van gegevens 
e Voorbeelden: queryprocessors, XML-documentmakers 


Figuur 11-11 De twee soorten OLE DB-dienstverleners 


Een serviceprovider (dienstverlener) daarentegen transformeert de gegevens. Service- 
providers accepteren OLE DB-gegevens van een tabulaire OLE DB-gegevens- 
leverancier en transformeren die op een of andere manier. Serviceproviders zijn 
zowel consumenten als leveranciers van getransformeerde gegevens. Een service- 
provider kan bijvoorbeeld gegevens uit een relationeel DBMS halen en die transfor- 
meren naar XML-documenten. Gegevensleveranciers en serviceproviders verwerken 
beide rowsetobjecten. Een rowset is hetzelfde als wat we in hoofdstuk g cursors 
noemden — de twee termen worden vaak als synoniemen gebruikt. 

Rowsets worden in het geval van databaseapplicaties gemaakt door SQL-state- 
ments te verwerken. De resultaten van een query worden bijvoorbeeld opgeslagen in 
een rowset. OLE DB-rowsets hebben tientallen verschillende methoden, die toegan- 
kelijk zijn via de in Figuur 11-12 getoonde interfaces. 

lRowSet biedt objectmethoden voor forward only-sequentiële beweging in een 
rowset. Als je in OLE DB een forward only-cursor declareert, roep je de IRowSet- 
interface aan. De lAccessor-interface wordt gebruikt om programmavariabelen aan 
rowsetvelden te koppelen. 


De IColumnsInfo-interface beschikt over methoden om informatie over de ko- 
lommen in een rowset op te vragen. IRowSet, lAccessor en IColumnslInfo zijn de 
standaardrowsetinterfaces. Andere interfaces worden gedefinieerd voor meer ge- 
avanceerde bewerkingen, zoals schuifbare cursors, wijzigingen, directe toegang tot 


bepaalde rijen en expliciete locks. 
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e IRowSet 


Methoden voor sequentiële iteratie door een rowset 
e lAccessor 


Methoden voor het instellen en bepalen van koppelingen tussen 
rowset en clientprogrammavariabelen 
e [Columnslinfo 


Methoden voor het opvragen van informatie over de kolommen in de rowset |} 


e Andere interfaces 
Schuifbare cursors 
Maken, wijzigen en verwijderen van rijen 
Directe toegang tot bepaalde rijen (bladwijzers) 
Expliciete locks instellen 
Enzovoort 


Figuur 11-12 Rowsetinterfaces 


11.4 ADO en ADO.NET 


Omdat OLE DB een objectgeoriënteerde interface is, is deze speciaal geschikt voor 
objectgeoriënteerde talen als VB.NET en Visual C#.NET. Maar veel programmeurs 
van databaseapplicaties programmeren in scripttalen als VBScript of JScript (de Ja- 
vaScript-versie van Microsoft). Om aan de behoeften van deze programmeurs tege- 
moet te komen, ontwikkelde Microsoft Active Data Objects (ADO) als een eenvoudig 
objectmodel dat over het ingewikkelder objectmodel van OLE DB wordt gelegd. ADO 
kan worden aangeroepen vanuit scripttalen zoals JScript en VBScript, evenals vanuit 
krachtiger talen zoals Visual Basic .NET, Java, Visual C#.NET, Visual C++.NET en 
zelfs vanuit Java. Omdat ADO makkelijker te begrijpen en te gebruiken is dan OLE 
DB, werd (en-wordt) het vaak gebruikt voor databaseapplicaties. 

ADO.NET is een nieuwe, verbeterde en uitgebreide versie van ADO, die de func- 
Horfaliteït van ADO en OLE DB bevat en nog veel meer. In het bijzonder kun je met 


ADO.NET XML-documenten maken van en omzetten naar relationele databases. In_ 


Figuur 11-13 zie je de rol van ADO.NET. 


ENTER 
ADO.NET | DBMS EE 
Windows- Ees XML- 
aplesies Webapplicaties 


Figuur 11-13 De rol van ADO.NET 
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11.4.1 Het objectmodel van ADO.NET 

Laten we het ADO.NET-objectmodel wat beter bekijken. Zoals te zien is in Figuur 
1-14, is de ADO.NET Data Provider een klassenbibliotheek met ADO.NET-services. 
Er zijn Data Providers voor ODBC, OLE DB, SQL Server en EDM, wat betekent dat 
ADO.NET niet alleen met de ODBC en OLE DB werkt, maar ook direct met SQL 
Server en met .NET-applicaties die EDM gebruiken. 


De eed 


Of andere 
OLE DB- 
data source 


ADO.NET data provider 


Connection 


‚NET data providers: 


SQLClient 

OracleClient Data Data 

Overige.… Reader Adapter 
[_Á 


Y 


XML- 
document 


mn 


Applicatie 


Applicatie 


Figuur 11-14 De onderdelen van een ADO.NET Data Provider 


Een vereenvoudigde versie van het ADO.NET-objectmodel zie je in Figuur 11-15. De 
klassen van ADO.NET zijn onderverdeeld in Data Providers en DataSets. 


Het ADO.NET Connection-object is verantwoordelijk voor de verbinding met de 
gegevensbron. 

De ADO.NET DataSet bevat een representatie van de gegevens die in het geheu- 
gen van de computer zijn opgeslagen, naast de gegevens die in het DBMS zitten. De 
DataSet is gescheiden en onafhankelijk van de DBMS-gegevens. Dat betekent dat 
je opdrachten op de DataSet kunt uitvoeren in plaats van op de feitelijke gegevens. 
Het is mogelijk dat gegevens in de DataSet uit verschillende databases komen en 
beheerd worden door verschillende DBMS-producten. De DataSet bevat de Data- 
TableColletion en de DataRelationCollection. Een meer gedetailleerde versie van het 
ADO.NET-DataSet-Objectmodel zie je in Figuur 11-16. 


De DataTableCollection is een nabootsing van de tabellen van het DBMS door 


middel van DataTable-objecten. DataTable-objecten bevatten een DataColumn- 
collectie, een DataRow-collectie en Constraints. Gegevenswaarden worden in een 
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DataSet 


Î Data Providers Data Consumers 


Connection 


A 


DataTableCollection 
DataTable 


Columns 


> Data Adapter < | Rows > 


Contraints 


DataRelationCollection 


Relationships 


bh Command 4 


| 


Y 
Data Reader < 


Figuur 11-15 Het ADO.NET-objectmodel 


DataRow-collectie op drie manieren opgeslagen: de originele waarden, de huidige 
waarden en de voorgestelde waarden. Elk DataTable-object heeft een PrimaryKey- 
property om uniciteit van de rij af te dwingen. In de Constraint-collectie komen twee 
soorten constraints voor. De ForeignKeyConstraint zorgt voor de referentiële integri- 
teit, de UniqueConstraint voor de gegevensintegriteit. 

De DataRelationCollection bewaart DataRelations, die fungeren als relationele 
verwijzing tussen tabellen. Relaties tussen tabellen uit de DataSet kun je op dezelfde 
manier verwerken als relaties in een database. Je kunt bijvoorbeeld een relatie ge- 
bruiken om de waarden van een kolom te berekenen en DataSet-tabellen kunnen 
ook views hebben. 

Het ADO.NET Command-object dat je in Figuur 11-14 en Figuur 11-15 ziet, fun- 
geert als SQL-opdracht of opgeslagen procedure op de gegevens in de DataSet. De 
ADO.NET DataAdapter is de verbinding tussen het Connection-object en het Data- 
Set-object. De DataAdapter gebruikt vier soorten opdrachten: SelectCommand, In- 
sertCommand, UpdateCommand en DeleteCommand. 

SelectCommand haalt gegevens uit de database en plaatst deze in een DataSet. De 
andere opdrachten sturen wijzigingen in de DataSet terug naar de databasegegevens. 
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DataTable 


EEEN eee 
EEN en 
E onscoumnotscen CT 
p- LT Eendedroperties 4 


Figuur 11-16 Het ADO.NET-DataSet-Objectmodel 


De ADO.NET DataReader is vergelijkbaar met een cursor die read-only, forward-only 
gegevens levert uit een datasource. Als we vast vooruitkijken naar hoofdstuk 12 over 
XML, dan zien we al wat voordelen van ADO.NET boven ADO. Als er eenmaal een 
DataSet gemaakt is, kan met een enkele opdracht de inhoud in een XML-document 
worden geplaatst. Omgekeerd werkt het ook. Een XML Schema-document kun je 
gebruiken om de structuur van een DataSet te maken en daarna kun je de DataSet 
vullen met gegevens door een XML-document te lezen. 


Opmerking 

Je kunt je afvragen waarom dit allemaal nodig is. Waarom hebben we een database in het geheugen 
nodig? Het antwoord komt in het volgende hoofdstuk en heeft betrekking op een databaseview zoals in 
Figuur 12-25 is te zien. Deze view is tot stand gekomen via twee meerwaardige paden door de gegevens. 
Er is in SQL geen standaardmanier om dat voor elkaar te krijgen. In plaats daarvan moet je twee SQL- 
statements uitvoeren en de resultaten daarvan op de een of andere manier aan elkaar koppelen. Views 
als in Figuur 12-25 worden al jaren gemaakt. Een programmeur schrijft dan een programma om de 
gegevens in het geheugen te manipuleren en in de database op te slaan. 
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DataSets hebben ook een nadeel. Omdat de gegevens in de DataSet niet verbonden 
zijn met de gewone database, kun je alleen optimistische locking toepassen. De ge- 
gevens worden uit de database gelezen, in de DataSet geplaatst en daar bewerkt. Er 
wordt geen poging gedaan wijzigingen in de DataSet terug te voeren naar de data- 
base. Als de applicatie na verloop van tijd de gegevens van de DataSet in de database 
wil opslaan, is optimistische locking nodig. Als een andere applicatie de gegevens 
veranderd heeft, moet of de DataSet opnieuw bewerkt worden, of de wijziging van de 
DataSet komt in de database terecht, met het lost update-probleem als gevolg. 

Dat betekent dat DataSets niet gebruikt kunnen worden in toepassingen waarin 
optimistische locking problematisch is. Voor zulke toepassingen moet je het ADO. 
NET Command-object gebruiken. 


11.5 Het Java-platform 


Nu we naar het Microsoft .NET Framework hebben gekeken, richten we onze aan- 
dacht op het Java-platform. 


11.5.1 JDBC 
JDBC staat voor Java Database Connectivity van Sun Microsystems. Er zijn JDBC- 
drivers beschikbaar voor bijna elk DBMS-product. Sommige zijn gratis en andere 
zijn gratis gedurende een beperkte periode. 

Zoals je in Figuur 11-17 kunt zien, levert Sun vier drivertypen. 


Drivertype [Eigenschappen Eel 
1 JDBC-ODBC bridge. Levert een Java-API om ODBC aan te sturen. Stelt je in staat om ODBC 
|datasources vanuit Java te bewerken. dl 
2 Een Java-API die een verbinding maakt met de systeembibliotheek van een DBMS-product. 
Het Java-programma en het DBMS moeten zich op dezelfde machine bevinden, zo niet, 
| dan moet het DBMS zorgen voor de communicatie tussen de twee machines. 
| 3 Een Java-API voor verbinding via een DBMS- onafhankelijk netwerkprotocol. Kan worden 


Ie gebruikt voor servlets en applets. 
4 Een Java-API voor verbinding via een DBMS-afhankelijk netwerkprotocol. Kan worden 


an gebruikt voor servlets en applets. el 


Figuur 11-17 Overzicht van JOBC-drivertypen 


Drivertype 1 vormt een brug tussen Java en ODBC. De meeste ODBC-drivers zijn 
geschreven in C of C++. Omdat Java niet geheel compatibel is met C/C++ is er een 
brug nodig in de vorm van een JDBC-ODBC-bridge driver. 

Drivers van type 2 maken rechtstreeks verbinding met de API van het DBMS, 
zonder tussenkomst van ODBC. Drivers van type 3 en 4 zijn bedoeld voor gebruik 
in een netwerk. 

Om te kunnen begrijpen hoe drivers van de typen 2 tot en met 4 van elkaar ver- 
schillen, moet je eerst weten wat het verschil is tussen een servlet en een applet. Zo- 
als je waarschijnlijk weet, is Java ontworpen om overdraagbaar (portable) te zijn. 
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Daarom worden Java-programma's niet vertaald naar een specifieke machinetaal, 
maar naar machine-onafhankelijke bytecode. Sun, Microsoft en andere firma’s heb- 
ben bytecode-interpreters geschreven voor verschillende typen machines (Intel, Alp- 
ha, enzovoort). Deze interpreters heten Java Virtual Machines. 

Om een vertaald Java-programma uit te voeren, moet de machine-onafhankelijke 
bytecode door de interpreter in runtime worden vertaald. Dit kost natuurlijk tijd, 
waardoor een dergelijk programma nooit zo snel kan zijn als een programma dat di- 
rect in machinecode is vertaald. In de praktijk hoeft dit geen probleem te zijn, het is 
bovendien afhankelijk van het soort applicatie. 

Een applet is een programma in Java-bytecode dat draait op de computer van de 
gebruiker. De bytecode wordt via http verzonden naar de gebruiker. De bytecode 
wordt geïnterpreteerd door een virtuele machine die gewoonlijk onderdeel is van een 
browser. Vanwege de overdraagbaarheid kan dezelfde bytecode worden verzonden 
naar een Windows-, UNIX- of Apple-computer. 

Een servlet is een Javaprogramma dat via http wordt aangeroepen op de computer 
van de webserver. Servlets worden geïnterpreteerd door een virtuele machine die op 
de server draait. Servlets antwoorden op verzoeken van browsers. 

Omdat drivers van type 3 en 4 toegang hebben via een netwerkprotocol, kun je 


deze drivers in servlets en applets gebruiken. Als je DBMS een type 4-driver heeft, 
zal deze sneller zijn dan die van type 3. 


11.5.2 JDBC gebruiken 


In tegenstelling tot ODBC heeft JDBC geen apart hulpprogramma voor het maken 
van een datasource. In plaats daarvan wordt al het werk om de verbinding te maken 


gedaan door de JDBC-driver. Het gebruik van een JDBC-driver gaat in principe als 
volgt: 


1. Laad de driver. 

2. Maak een verbinding met de database. 
3. Maak een opdracht. 

4. Doe iets met de opdracht. 


Figuur 11-18 geeft een overzicht van de onderdelen van JDBC. 


Merk op dat in deze figuur Java wordt gebruikt om de applicatie te schrijven. Omdat 
Java een objectgeoriënteerde taal is, zien we in de applicatie een verzameling objec- 
ten die vergelijkbaar zijn met die we besproken hebben bij ADO.NET. De applicatie 
maakt een Connection-object, een Statement-, een ResultSet- en een ResultSetMe- 
taData-object. Opdrachten vanuit deze objecten worden via de Driver Manager naar 
de juiste driver gestuurd. De driver spreekt dan de database aan. Merk op dat de 
Oracle-database in deze figuur kan worden aangesproken via JDBC-ODBC of via een 
eigen JDBC-driver. 
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Figuur 11-18 Overzicht van de onderdelen van JDBC 


11.5.3 JSP en Servlets 

Java Server Pages (JSP) is een technologie om dynamische webpagina's met behulp 
van Java te maken. Door Java heeft de webontwikkelaar de beschikking over een 
complete objectgeoriënteerde taal. Dit is vergelijkbaar met wat je kunt doen in ASP. 
NET met de Microsoft ‚NET talen. Omdat Java machine-onafhankelijk is, is JSP dat 
ook. Je kunt dezelfde JSP-pagina draaien op een Linux-server, Windows-server of 
welke dan ook. 


11.6 Web-databaseverwerking met PHP 


Het is nu tijd om een web-databaseapplicatie te maken en wat kennis uit dit hoofd- 
stuk en een paar nieuwe technieken toe te passen. Hoewel we technologieën als 
ADO.NET, ASP.NET, Java en JSP hebben geïntroduceerd, zijn dit complexe onder- 
werpen die buiten het kader van dit boek vallen. 

Daarom zullen we een eenvoudiger technologie gebruiken die kan worden toe- 
gepast met elk besturingssysteem of DBMS. We zullen de taal PHP gebruiken. PHP 
is een afkorting van PHP: Hypertext Processor. PHP is buitengewoon populair. Er 
zijn op de wereld miljoenen webservers die PHP ondersteunen. PHP is bovendien 
relatief makkelijk te leren. 

PHP wordt vaak in combinatie gebruikt met de Apache-webserver en MySQL 
(AMP), draaiend onder Linux (LAMP) of onder Windows (WAMP). 


11.6.1 De webserver 


Hoewel Apache de meest gebruikte webserver is en op vrijwel elk besturingssysteem 
draait, gebruiken we in dit boek de Microsoft [IS-webserver. IIS is een afkorting van 
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Internet Information Server. Een voordeel van het gebruik van deze webserver voor 
gebruikers van Windows XP Professional of Vista is dat IIS onderdeel is van het be- 
sturingssysteem. Dat betekent dat de gebruiker daarvan kan oefenen met een web- 
server op zijn eigen computer. IIS wordt niet automatisch geïnstalleerd maar dat 
kan makkelijk worden gedaan. De beschrijving in de volgende paragrafen geldt met 
minieme wijzigingen ook voor de Apache-webserver. 

Als IIS is geïnstalleerd, maakt het een map op de C:-schijf aan: C:\inetpub. In 
deze map is een map wwwroot, waarin IIS de meest basale webpagina’s plaatst die 
de webserver gebruikt. IIS kun je beheren met behulp van het programma [IS Ma- 
nager. In Vista vind je dit programma onder Control Panel, Administrative Tools. In 
Windows Server 2008 open je Start | Administrative Tools | IIS Manager. 

Om de installatie van de webserver te testen, open je een browser en typ je in als 
locatie: http://localhost. 

Als het goed is, verschijnt er een welkomstpagina vergelijkbaar met die in Figuur 
11-19. Als de juiste pagina niet wordt getoond, is er iets mis met de installatie van je 
webserver. 

We gaan nu een kleine website maken waarin we de VRG-database kunnen ge- 
bruiken. Maak daartoe (met Windows Explorer) eerst een map met de naam DBC 


(Database Processing) in de map wwwroot. Maak vervolgens in DBC een map VRG. 
Hierin plaatsen we de website van VRG. 


Deze webpagina is 
gegenereerd met 
behulp van het 
isstart.htm bestand 
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Figuur 11-19 De welkomstpagina van IIS 


Pp Na vecal manet | Protected Mode: OT a HOR ee 4 


11.6.2 Beginnen met HTML 

De meest eenvoudige webpagina's zijn gemaakt met de Hypertext Markup Language 
(HTML). De term hypertext verwijst naar het feit dat je links kunt invoegen naar an- 
dere objecten, zoals webpagina's, afbeeldingen, audio en video. HTML zelf bestaat 
uit een standaardverzameling regels en zogeheten tags die webbrowsers gebruiken 
om de pagina op te maken. 
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Tags komen meestal in paren voor. Bijvoorbeeld <p> geeft het begin van een nieuwe 
alinea (paragraph) aan, </p> het einde van die alinea. De tag <hr> betekent het begin 
van een kop (header) boven een artikel, </hr> het einde van de kop. Tussen de twee 
tags kun je de nodige tekst plaatsen. Bijvoorbeeld <hi>Hier staat de kop</hi>. De 
webbrowser zal de tags weglaten, maar de tekst Hier staat de kop groot en vet afbeel- 
den. Op internet zijn veel goede handleidingen voor HTML te vinden. 


11.6.3 Het bestand index.html 

We maken in dit hoofdstuk een eenvoudige homepage voor galerie View Ridge. Hoe- 
wel er talloze editors voor webpagina's bestaan, is alles wat je nodig hebt een eenvou- 
dige tekstverwerker, zoals Windows Notepad (Kladblok). 

De naam van het bestand dat we gaan maken is index.html. Deze naam heeft voor 
de meeste webservers een speciale betekenis. De pagina zal automatisch worden ge- 
toond als een browser een verzoek doet zonder een bestand te specificeren. Let op 
de zinsnede meeste webservers. Apache en [IS 7 herkennen index.html automatisch, 
maar dat geldt niet voor Windows XP met IIS 5.1. In het laatste geval moet je index. 
html met het managementprogramma toevoegen aan de lijst met recognized files. 

Maak in Kladblok het bestand index.html met de inhoud van Figuur 11-20. Let op 
het inspringen in de code om deze leesbaar te houden. 


html “-//W3C//DTD HTML 4.01 Strict//EN" 


n ntent="text /html: narsct 7-385A- 


zeauiv="Content=Tyr zor n 


ï 7u n YI xt/h s &l 
View Ridge Gallery Demonstration Pages Home Page 


„"text=-alian: cent Lue” 
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style="text-align: center; font-weight: bold" 
David M. Kroenke 


e"texte-al 


align: center; font=weight: bold" 


d yì 1 
David J. Auer 


tyie Lex 


We lcom 


Chapter 11 Demonstration Pages From Figures in the Text: 
Example l:ánbsp;&nbsp;&nbsp; 
href="ReadArtist.php" 


Display the ARTIST Table (LastName, FirstName, Nationality) 


Figuur 11-20 Het bestand index.html voor VRG 
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Bewaar het bestand index.html in de map DBC\VRG die eerder gemaakt is (zie pa- 
ragraaf 11.61). 

Open je browser en typ de volgende URL: http://localhost/DBC/VRG. Als de 
webserver op een andere computer draait, gebruik je http://{DNS naam van de web- 
server of het IP-adres}/DBC/VRG. Als het goed is, krijg je een pagina te zien als in 
Figuur 11-21. 


Dit IP-adres geeft aan S en En 
dat in ons geval de ELD hed vis hee [CEN oost 

webserver op een pe 5 nemesis kf „e : 

andere computer draait. AC (B Ven Brie Gatery Demonstration Pages Home P CAN eK mv Pager Salet Toor adr 


Als hij op je eigen Br 
computer draait, 
gebruik dan 


http:/localhost/DBC/VRG. 


Figuur 11-21 De index.html webpage in VRG 


11.6.4 PHP installeren 


Nu we de basis voor de website hebben opgezet, gaan we PHP gebruiken om een ver- 
binding met de VRG-database te maken. PHP kun je gratis downloaden van www. 
php.net. Het installeren van PHP vergt verscheidene stappen, dus neem daar even 
de tijd voor. Overtuig je er ook van dat je PHP Data Objects (PDO) inschakelt. Dit 


gebeurt niet automatisch. 


11.6.5 Eclipse installeren 


Hoewel Notepad geschikt is voor het maken van eenvoudige webpagina's, gebruiken 
we voor complexere pagina's een zogeheten Integrated Development Environment 
(IDE of geïntegreerde ontwikkelomgeving). Een mogelijkheid is Visual Studio Ex- 
press. In dit hoofdstuk gebruiken we Eclipse met de PHP Development Tools (PDT). 
Zie www.eclipse.org/pdt voor algemene informatie en http://www.eclipse.org/pdt/ 
downloads voor het downloaden van de files. Voor het gebruik van Eclipse met PDT 
moet je ook de Java Runtime Environment (JRE) van Sun Microsystems installeren. 


Database Processing (11th Edition) 
David M. Kroenke 


David J. Auer 


Welcome to the View Ridge Gallery Home Page 


Chapter 11 Demenstranon Pages From Fies in the Text 


Example | Dogtre tbe ARTIST Table (LautName, FastName, Nanonakts) 


De code van het bestand index.html in Eclipse zie je in Figuur 11-22. 
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Het DBP-e11-VRG- en ae en en SE 
project-Eclipse bundelt Prov #7 „ Hem « ERE) oenen 
werk in projecten meu Epen = etheen GE 


De code van 


index.html — merkop |_—” 


hoe de kleuren de 


leesbaarheid vergroten 


Figuur 11-22 Het bestand index.html in Eclipse 


11.6.6 Het bestand ReadArtist.php 

We gaan nu PHP gebruiken voor onze website. We maken eerst een pagina om de 
gegevens van een tabel uit de database te lezen en de resultaten op een webpagina te 
tonen. We doen dit door middel van een bestand ReadArtist.php dat we in de map 
DBC\VRG plaatsen en dat onder meer de volgende query uitvoert: 


SELECT LastName, FirstName, Nationality FROM ARTIST; 
De HTML- and PHP-code van ReadArtist.php zie je in Figuur 11-23. 


Typ nu in je browser de URL http://localhost/DBP/VRG en klik vervolgens op de 
link Example r: Display the ARTIST Table (No surrogate key). Je ziet dan een webpa- 
gina als in Figuur 11-24. 

De code in ReadArtist.php is een mengsel van HTML en PHP. Het gedeelte in 
de code tussen de tags <?php en >> is programmacode die op de computer van de 
webserver wordt uitgevoerd. De rest van de code is HTML die naar de browser van 
de client wordt gestuurd. 


11.6.7 Een databaseverbinding maken 
In Figuur 11-23 zorgt de volgende PHP-code, die is ingebed in HTML, voor het ma- 
ken en testen van een verbinding met de database: 


<?php 
// maak verbinding database 
$DSN = "VRG"; 
$User = "VRG-User": 
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$Password = “VRG-Usertpassword”; 
$Conn = odbc_connect($DSN, $User, $Password); 


// Test verbinding 
if (!$Conn) 
{ 
exit (“ODBC Connection Failed:” . $Conn); 


HTML "-//W3C//DTD HTML 4.01 Frameset//EN" 


http-equiv c 
ReadArtist PHP Page 
type=" 1 


SPassword = "VRG- 


SConn = odbe connect ( 


if (!SConn) 


exit (“OD 
} 


SSQL = "57 


SRecordSet = odbe_exec ($Conn, SSQr) B 


1f (1SRecordSet) 
{ 


Figuur 11-23 De HTMI- en PHP-code voor ReadArtist.php 
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pit IP-adres geeft aan 
dat de webserver op 
een andere computer 
draait. Als de webserver B 
op je eigen computer Í 5 ee: 
draait, gebruik dan | ge Gallery Artist Table 
| htip:MocalhosYDBC/VRG.| || 


Klik hier om terug te LastName EE) REED 
an Spans 
keren naar de S rl 
Homepage van VRG = 
gn 


German 


© Internet | Protected Mode On av KX v 


Figuur 11-24 De resultaten van ReadaArtist.php 


In PHP-code kun je een dubbele slash // gebruiken om er commentaar achter te 
plaatsen. Je kunt ook /* en */ gebruiken om er commentaar tussen te zetten. In 
HTML moet commentaar tussen de symbolen <!-- en --> staan. De gebruikersnaam 
en het wachtwoord hebben we in hoofdstuk ro gemaakt (zie paragraaf 10.8). De 
variabele $Conn bevat informatie over de verbinding. 


Het testen van de verbinding gebeurt met: 


if (1$Conn) 
{ 
exit (“ODBC Connection Failed:" . $Conn); 


Het uitroepteken voor $Conn betekent NOT. In gewoon Nederlands staat er: als de 
verbinding $Conn niet bestaat, toon dan een foutmelding en verlaat het programma. 

Als de verbinding wel tot stand is gekomen, is de database open en kun je vanaf 
dat punt de variabele $Conn gebruiken op alle plaatsen waar je een verbinding met 


de database nodig hebt. 


11.6.8 Een Recordset maken 
Als je verbinding met een open database hebt, gebruik je het volgende stukje code uit 


Figuur 11-23 om een SQL-opdracht op te slaan in een variabele met de naam $SQL. 
Vervolgens laat je met de PHP-opdracht odbc_exec die op 
de database, waarbij je de resultaten terugkrijgt in de variabele $RecordSet: 
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$Password = “VRG-Usertpassword”; 
$Conn = odbc_connect($DSN, $User, $Password); 


// Test verbinding 
if (!$Conn) 
{ 
exit (“ODBC Connection Failed:” . $Conn); 


HTML "-//W3C//DTD HTML 4.01 Frameset//EN" 


http-equiv c 
ReadArtist PHP Page 
type=" 1 


SPassword = "VRG- 


SConn = odbe connect ( 


if (!SConn) 


exit (“OD 
} 


SSQL = "57 


SRecordSet = odbe_exec ($Conn, SSQr) B 


1f (1SRecordSet) 
{ 


Figuur 11-23 De HTMI- en PHP-code voor ReadArtist.php 
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Figuur 11-24 De resultaten van ReadaArtist.php 


In PHP-code kun je een dubbele slash // gebruiken om er commentaar achter te 
plaatsen. Je kunt ook /* en */ gebruiken om er commentaar tussen te zetten. In 
HTML moet commentaar tussen de symbolen <!-- en --> staan. De gebruikersnaam 
en het wachtwoord hebben we in hoofdstuk ro gemaakt (zie paragraaf 10.8). De 
variabele $Conn bevat informatie over de verbinding. 


Het testen van de verbinding gebeurt met: 


if (1$Conn) 
{ 
exit (“ODBC Connection Failed:" . $Conn); 


Het uitroepteken voor $Conn betekent NOT. In gewoon Nederlands staat er: als de 
verbinding $Conn niet bestaat, toon dan een foutmelding en verlaat het programma. 

Als de verbinding wel tot stand is gekomen, is de database open en kun je vanaf 
dat punt de variabele $Conn gebruiken op alle plaatsen waar je een verbinding met 


de database nodig hebt. 


11.6.8 Een Recordset maken 
Als je verbinding met een open database hebt, gebruik je het volgende stukje code uit 


Figuur 11-23 om een SQL-opdracht op te slaan in een variabele met de naam $SQL. 
Vervolgens laat je met de PHP-opdracht odbc_exec die op 
de database, waarbij je de resultaten terugkrijgt in de variabele $RecordSet: 
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// Maak SQL-statement 
$SQL = "SELECT LastName, FirstName, Nationality FROM ARTIST"; 


// Voer statement uit 
$RecordSet = odbc _exec($objConn, $SQL); 


// Test statement 

if (1$RecordSet) 

{ 

exit (“SQL Statement Error:” . $SQL); 
} 

2> 


Merk op dat je het resultaat moet testen om er zeker van te zijn dat het SQL-state- 
ment correct is uitgevoerd. 


11.6.9 De resultaten op het scherm zetten 


Nu de recordset met de naam $RecordSet gemaakt en gevuld is, verwerk je hem met 
de volgende code: 
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<l-- Page Headers --> 
<h1> 
The View Ridge Gallery ARTIST Table 
</hl> 
<hr/> 
<h2> 
ARTIST 
</h2> 
<?php 
// Table headers 
echo "<table class='output' border='1"> 
<tr> 
<th>LastName</th> 
<th>FirstName</th> 
<th>Nationality</th> 
</tr>"; 
// Table data 
while($RecordSetRow = odbc_fetch_array($RecordSet)) 
{ 
echo "<trò'; 
echo "<td>" . $RecordSetRow['LastName'] . "</td>"; 
echo "<td>" . $RecordSetRow['FirstName'] . "</td>"; 
echo “<td>” . $RecordSetRow['Nationality'] . "</td>"; 
echo "</tr>"; 
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} 
echo "</table>"; 


Het HTML-gedeelte definieert de koppen van de pagina, het PHP-gedeelte definieert 
de uitvoer in tabelformaat. Merk op dat het gebruik van de PHP-opdracht echo je in 
staat stelt HTML-code te gebruiken in het PHP-gedeelte. Merk ook op dat de varia- 
bele SRecordSetRow wordt gebruikt om de rijen van $RecordSet één voor één af te 
lopen. 


11.6.10 De verbinding met de database verbreken 
Als de SQL-opdrachten klaar zijn met de uitvoering en het resultaat getoond is, kun 
je de ODBC-verbinding met de database beëindigen: 


// sluit verbinding 
odbe _close($Conn); 
2D 


11.6.11 Verder met PHP 

In de vorige paragrafen lieten we de grondbeginselen zien van het gebruik van 
ODBC en PHP voor het maken van een databaseverbinding en het verwerken van 
gegevens in een webapplicatie. Over het gebruik van PHP in webapplicaties valt ui- 
teraard veel meer te leren, maar dat valt buiten het bestek van dit boek. Meer infor- 
matie over PHP kun je vinden op www.php.net/docs.php. 


Samenvatting 


Databaseapplicaties bestaan tegenwoordig in een uitgebreide en gecompliceerde 
omgeving. Naast relationele databases bestaan er niet-relationele databases, VSAM 
en andere bestandsverwerkende gegevens, e-mail en andere soorten gegevens. Er 
zijn diverse standaarden ontwikkeld om het leven van de applicatieprogrammeur 
wat eenvoudiger te maken. De standaard ODBC is opgesteld voor relationele data- 
bases, de standaard OLE DB is bedoeld voor relationele en andere datasources. ADO 
is ontwikkeld om de niet-objectgeoriënteerde programmeur eenvoudiger toegang te 
bieden tot OLE DB-gegevens. 

ODBC of de standaard-Open Database Connectivity voorziet in een interface 
waarmee webservers relationele datasources op een DBMS-onafhankelijke manier 
kunnen benaderen en verwerken. ODBC is ontwikkeld door een industriecommis- 
sie en geïmplementeerd door Microsoft en vele andere leveranciers. ODBC bestaat 
uit applicaties, een driver-manager, een DBMS-driver en datasourcecomponenten. 
Er worden single-tier en multi-tier drivers gedefinieerd. Er zijn drie typen datasour- 
cenamen: bestandsnaam, system Data Source Name en user Data Source Name 
(DSN). System datasources worden aanbevolen voor webservers. Bij het definiëren 


van een systeemdatasource worden het type driver en de identiteit van de te verwer- 
ken database opgegeven. 
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OLE DB vormt de basis van gegevensbenadering met Microsoft-producten. Het 
implementeert de Microsoft-standaarden OLE en COM en is toegankelijk voor ob- 
jectgeoriënteerde programma’s via die interfaces. OLE DB deelt de functies en mo- 
gelijkheden van een DBMS op in objecten, waardoor leveranciers eenvoudiger delen 
van hun functionaliteit kunnen implementeren. Belangrijke objecttermen zijn: ab- 
stractie, methoden, eigenschappen en collecties. Een rowset is een abstractie van 
een recordset en een recordset is een abstractie van een relatie. Objecten worden 
gedefinieerd met behulp van gegevens en methoden. Een collectie is een object dat 
een groep andere objecten bevat. De doelstellingen van OLE DB staan opgesomd in 
Figuur 11-10. Een interface is een collectie objecten met de door die objecten getoon- 
de eigenschappen en methoden. Objecten kunnen verschillende eigenschappen en 
methoden in verschillende interfaces tonen. Een implementatie is de manier waarop 
een object zijn taken uitvoert. Implementaties zijn verborgen voor de buitenwereld 
en kunnen worden gewijzigd zonder de gebruikers van de objecten lastig te vallen. 
Een interface mag nooit worden gewijzigd. 

Tabulaire gegevensleveranciers tonen gegevens in de vorm van rowsets. Service- 
providers transformeren gegevens naar een andere vorm — zulke providers zijn zo- 
wel consumenten als leveranciers van gegevens. Een rowset is het equivalent van een 
cursor. De standaard-rowsetinterfaces zijn IRowSet, IAccessor en IColumnsinfo. 
Andere interfaces worden voor meer geavanceerde taken gedefinieerd. 

ADO.NET is een nieuwe, verbeterde en uitgebreide versie van ADO, ontwikkeld 
voor het Microsoft ‚NET-platform. ADO.NET biedt de mogelijkheid databasegege- 
vens om te zetten van en naar XML-documenten. 

Het belangrijkste nieuwe concept van ADO.NET is de DataSet. Een DataSet is 
een database in het geheugen die niet is verbonden met de gewone database maar 
wel alle belangrijke eigenschappen van een gewone database heeft. DataSets kun- 
nen meerdere tabellen hebben, relaties, regels en acties voor referentiële integriteit, 
views en het equivalent voor triggers. Tabellen in een DataSet kunnen een primaire 
sleutel hebben en surrogaatsleutels (die auto-increment-kolommen heten). Je kunt 
makkelijk een XML-document maken van de inhoud van een DataSet, of een XML- 
schema van zijn structuur. En ook omgekeerd. 

DataSets zijn nodig om gestandaardiseerde, niet-productafhankelijke views van 
een database te maken. Ze zijn in het bijzonder belangrijk voor het maken van views 
met meerwaardige paden. Een mogelijk nadeel van een DataSet is dat je optimisti- 
sche locking moet toepassen omdat de DataSet niet verbonden is met de database. 
Als er een conflict optreedt, moet of de DataSet opnieuw verwerkt worden, of de 
wijziging in de DataSet komt in de database terecht, wat een lost update-probleem 
oplevert. 

JDBC is een alternatief voor ODBC en ADO dat databasetoegang vanuit Java- 
programma’s mogelijk maakt. Er is voor vrijwel elk DBMS-product een JDBC-driver 
beschikbaar. Drivers van type 1 vormen een brug tussen Java en ODBC. Drivers van 
type 2 laten zo nodig de communicatie tussen verschillende machines over aan het 
DBMS-product. Drivers van type 3 vertalen JDBC-opdrachten naar een DBMS-on- 
afhankelijk netwerkprotocol. Drivers van type 4 vertalen JDBC-opdrachten naar 
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een DBMS-afhankelijk netwerkprotocolEen applet is een in bytecode vertaald Java- 
programma dat naar een browser wordt verzonden via HTTP. Een servlet is een 
Java-programma dat wordt aangeroepen op de server om te beantwoorden aan een 
http-verzoek. Drivers van type 3 en type 4 kun je voor zowel applets als servlets ge- 
bruiken. Drivers van type 2 kun je alleen in servlets gebruiken, en dan alleen als 
het DBMS en de webserver op dezelfde machine staan, of als het DBMS-product de 
communicatie tussen de webserver en de databaseserver verzorgt. 

Om JDBC te gebruiken, zijn er vier stappen nodig: (rt) laad de driver, (2) maak 
een verbinding met de database, (3) maak een opdracht, en (4) voer de opdracht uit. 

Java Server Pages (JSP) is een technologie die het mogelijk maakt dynamische 
webpagina's te maken, gebruikmakend van HTML (en XML) en Java. JSP geeft de 
ontwikkelaar de beschikking over een volledig objectgeoriënteerde taal. JSP-pagina's 
worden vertaald naar machine-onafhankelijke bytecode. 

PHP (PHP: Hypertext Processor) is een scripttaal die je in webpagina's kunt ge- 
bruiken. PHP is buitengewoon populair, is makkelijk te leren en kan worden ge- 
bruikt met de meeste webservers en de meeste databases. 

Om ingewikkelder pagina’s te maken, moet je een Integrated Development En- 
vironment (LDE) hebben. Een IDE geeft je een betrouwbare en gebruikersvriende- 
lijke manier om webpagina's te maken en te onderhouden. Microsoft Visual Studio 
en de opensource-IDE Eclipse zijn goede IDE's. Eclipse biedt een framework dat je 
kunt aanpassen met behulp van add-in-modules. Voor PHP is er een aanpassing van 
Eclipse die het Eclipse PDT Project heet en die speciaal bedoeld is om een PHP-ont- 
wikkelomgeving te maken. 

PHP heeft objectgeoriënteerde eigenschappen en PHP Data Objects (PDO), die 
het verbinden van webpagina's met databases vergemakkelijken. 


Belangrijke termen 


‚NET Framework 

2> 

<?php 

abstractie 

Active Data Objects (ADO) 
ADO.NET 

ADO.NET Command-object 
ADO.NET Connection-object 
ADO.NET Data Provider 
ADO.NET DataAdapter-object 
ADO.NET DataReader 
ADO.NET DataSet 
ADO.NET Entity Framework 
AMP 

Apache-webserver 

applet 


application program interface (API) 
ASP.NET 

bytecode-interpreter 

collectie 

Common Language Runtime (CLI) 
Component Object Model (COM) 
Cursor 

data consumer 

data provider 

DataColumn-collectie 
DataRelation-collectie 
DataRelations 

DataRow-collectie 

DataTable-object 
DataTableCollection 
DeleteCommand-object 
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Eclipse IDE 
Eclipse PDT (PHP Development Tools) 
Project 

Entity Data Model (EDM) 
Extensible Markup Language (XML) 
File data source 
ForeignKeyConstraint 

HTML document tags 
http://localhost 

Hypertext Markup Language (HTML) 
index.html 

inetpub-folder 
InsertCommand-object 

Integrated Development Environment 

(IDE) 

interface 

Internet Information Services (ILS) 
Internet Information Services Manager 
Java 

Java Data Objects (JDO) 

Java Database Connectivity (JBDC) 
Java-platform 

Java Server Page (JSP) 

Java virtuele machine 

JDBC Connection-object 

JDBC DriverManager 

JDBC ResultSet-object 

JDBC ResultSetMetaData-object 
JDBC Statement-object 

LAMP 


Oefeningen 


Geef aan waarom de data 
Wat is OLE DB en welk 
Leg uit waarom de aut 


Wat is de rol van de 

Wat is een single-tier driver? 
Wat is een multi-tier driver? 
Hebben het gebruik van d 


methode 

Microsoft Transaction Manager 
object 

Object Linking and Embeddin 
ODBC-conformiteitsniveau 
ODBC-datasource 

ODBC Data Source Administrator 
ODBC-driver 
ODBC-driver-manager 

ODBC multiple-tier driver 

ODBC single-tier driver 

ODBC SQL-conformiteitsniveau 
OLE DB 

Open Database Connectivity (ODBC) 
PHP 

PHP Data Objects (PDO) 

PHP: Hypertext Processor 
recordset 

rowset 

SelectCommand-object 
serviceprovider 

servlet 

system data source 

three-tier architecture 

two-tier architecture 
UniqueConstraint 
UpdateCommand-object 

user data source 

WAMP 

wwwroot-folder 


(MTs) 


8 (OLE) 


omgeving gecompliceerd is. 


nadeel van ODBC Is in OLE DB opgelost? 
van ven dit boek ervoor gekozen heeft om Microsoft 


levert deze manager? 


Wie levert deze driver? 


„ Geef een samenvatting van de drie gramm 


- Schrijf een stukje PHP-code om de ver 
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„ Waarom zijn conformiteitsniveaus belangrijk? 


Geef een Samenvatting van de drie ODBC API-conformiteitsniveaus. 


atische SQL-conformiteitsniveaus. 
Wat is het verschil tussen de drie typen datasources? 


„ Welk datasourcetype wordt aanbevolen voor webservers? 


Welke twee taken moeten worden uitgevoerd als een ODBC-datasourcenaam 
wordt ingesteld? 


„ Wat is het .NET-framework? 
„ Watisde huidige versie van .NET? 

„ Geef een definitie van abstractie en leg uit wat het verband ervan is met OLE DB. 
„ Geef een voorbeeld van abstractie waarbij een rowset betrokken is. 

„ Definieer object-eigenschappen en -methoden. 
„ Wat is het verschil tussen een objectklasse en een object? 

. Leg uit wat de rol is van gegevensconsumenten en gegevensleveranciers. 

„ Wat is een interface? 

. Wat is een recordset? 

. Leg uit waarom een implementatie wel kan worden gewijzigd, terwijl een inter- 


face nooit mag worden gewijzigd. 


. Geef een overzicht van de doelstellingen van OLE DB. 
. Wat is een MTS en wat is de functie ervan? 
. Leg uit wat het verschil is tussen een tabulaire gegevensleverancier en een ser- 


viceprovider. Welke zet OLE DB-gegevens om in XML-documenten? 


. Wat is in de context van OLE DB het verschil tussen een rowset en een cursor? 
. Watis ADO.NET? 


Wat is in ADO.NET een DataSet? 


. Wat is het belangrijkste nadeel van een DataSet in ADO.NET? Wanneer wordt 


dat een probleem? 
Wat betekent JDBC? 


„ Welke vier typen drivers kent JDBC? 


Geef de functie aan van elk van de vier typen drivers van JDBC. 


„ Wat is een applet? 

„ Wat is een servlet? 

„ Wat is het doel van Java Server Pages? 

. Waarom is index.html een belangrijke bestandsnaam? 
- Wat is PHP en welk doel heeft het? 

„ Hoe schrijf je PHP-code in webpagina's? 

- Wat is een IDE? 


Wat is Eclipse? f 
» Schrijf RA PHP-code om een verbinding met een database ee z 
- Schrijf een stukje PHP-code om de inhoud van een RecordSet zichtbaa 


en binding met een database te verbreken. 


DEEL 5 | STANDAARDEN VOOR DATABASETOEGANG 


Eclipse IDE 
Eclipse PDT (PHP Development Tools) 
Project 

Entity Data Model (EDM) 
Extensible Markup Language (XML) 
File data source 
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Hypertext Markup Language (HTML) 
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InsertCommand-object 
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interface 
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Java Database Connectivity (JBDC) 
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Java Server Page (JSP) 
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- Schrijf een stukje PHP-code om de ver 


DE WEBSERVEROMGEVING 


„ Waarom zijn conformiteitsniveaus belangrijk? 


Geef een Samenvatting van de drie ODBC API-conformiteitsniveaus. 


atische SQL-conformiteitsniveaus. 
Wat is het verschil tussen de drie typen datasources? 


„ Welk datasourcetype wordt aanbevolen voor webservers? 


Welke twee taken moeten worden uitgevoerd als een ODBC-datasourcenaam 
wordt ingesteld? 


„ Wat is het .NET-framework? 
„ Watisde huidige versie van .NET? 

„ Geef een definitie van abstractie en leg uit wat het verband ervan is met OLE DB. 
„ Geef een voorbeeld van abstractie waarbij een rowset betrokken is. 

„ Definieer object-eigenschappen en -methoden. 
„ Wat is het verschil tussen een objectklasse en een object? 

. Leg uit wat de rol is van gegevensconsumenten en gegevensleveranciers. 

„ Wat is een interface? 

. Wat is een recordset? 

. Leg uit waarom een implementatie wel kan worden gewijzigd, terwijl een inter- 


face nooit mag worden gewijzigd. 


. Geef een overzicht van de doelstellingen van OLE DB. 
. Wat is een MTS en wat is de functie ervan? 
. Leg uit wat het verschil is tussen een tabulaire gegevensleverancier en een ser- 


viceprovider. Welke zet OLE DB-gegevens om in XML-documenten? 


. Wat is in de context van OLE DB het verschil tussen een rowset en een cursor? 
. Watis ADO.NET? 


Wat is in ADO.NET een DataSet? 


. Wat is het belangrijkste nadeel van een DataSet in ADO.NET? Wanneer wordt 


dat een probleem? 
Wat betekent JDBC? 


„ Welke vier typen drivers kent JDBC? 


Geef de functie aan van elk van de vier typen drivers van JDBC. 


„ Wat is een applet? 

„ Wat is een servlet? 

„ Wat is het doel van Java Server Pages? 

. Waarom is index.html een belangrijke bestandsnaam? 
- Wat is PHP en welk doel heeft het? 

„ Hoe schrijf je PHP-code in webpagina's? 

- Wat is een IDE? 


Wat is Eclipse? f 
» Schrijf RA PHP-code om een verbinding met een database ee z 
- Schrijf een stukje PHP-code om de inhoud van een RecordSet zichtbaa 


en binding met een database te verbreken. 
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Projectvragen 


47. 


Microsoft doet veel moeite om de standaarden OLE DB en ADO te promoten, 
zonder dat het daar rechtstreeks iets aan verdient. IIS wordt gratis geleverd met 
Windows XP en 20oo, de website van Microsoft staat vol met artikelen om ont- 
wikkelaars te helpen meer over de standaarden te weten te komen, en dat alle- 
maal kosteloos. Waarom denk je dat Microsoft dit doet? Met andere woorden: 
wat denkt Microsoft ermee te bereiken? 


Marcia’s Chemische Reiniging 


Beantwoord vraag A tot en met G voor Marcia's Chemische Reiniging aan het eind 
van hoofdstuk 7, als je dat niet al hebt gedaan. Gebruik SQL Server (of Oracle, of 
MySQL) voor het implementeren van je database. 


À. 
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Maak een nieuwe map met de naam MCR. Maak een webpagina voor Marcia's 
Chemische Reiniging in deze map. Gebruik index.html als bestandsnaam voor 
deze pagina. 

Maak een geschikte datasource voor je database. 

Voeg de nieuwe kolom Status toe aan INVOICE. Neem aan dat Status de vol- 
gende waarden kan hebben: (“Waiting’, ‘In-process’, ‘Finished’, ‘Pending']. 
Maak een view met de naam CustomerOrder die de volgende kolommen heeft: 
LastName, FirstName, Phone, InvoiceNumber, Date, Total en Status. 

Maak een PHP-pagina voor het weergeven van CustomerOrder. Demonstreer 
met behulp van je voorbeelddatabase dat je pagina werkt. 

Maak twee HTML/PHP-pagina's voor het invoeren van een datumwaarde 
AsOfDate en het weergeven van rijen van CustomerOrder voor orders met een 
datum die na AsOfDate is of daaraan gelijk is. Demonstreer met behulp van je 
voorbeelddatabase dat je pagina’s werken. 

Maak twee HTML/PHP-pagina's voor het invoeren van Phone, LastName en 
FirstName van klanten en het weergeven van rijen van klanten met deze Phone, 
FirstName en LastName. Demonstreer met behulp van je voorbeelddatabase dat 
je pagina’s werken. 

Schrijf een opgeslagen procedure die waarden aanneemt voor InvoiceNumber 
en NewStatus en die de waarde van Status instelt op NewStatus voor de rij met 
de opgegeven waarde van InvoiceNumber. Lever een foutmelding als er geen rij 
is met de opgegeven waarde van InvoiceNumber. Demonstreer met behulp van 
je voorbeelddatabase dat je opgeslagen procedure werkt. 

Schrijf een PHP-pagina voor het aanroepen van de opgeslagen procedure die 
je in H hebt gemaakt. Demonstreer met behulp van je voorbeelddatabase dat je 
pagina werkt. 


dbi 
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Importbedrijf Morgan 


Beantwoord vraag A tot en met H voor Importbedrijf Morgan aan het eind van hoofd- 
stuk 7, als je dat niet al hebt gedaan. Gebruik SQL Server (of Oracle, of MySQL) voor 
het implementeren van je database. 


A. Maak een nieuwe map met de naam MI. Maak een webpagina voor Import- 
bedrijf Morgan in deze map. Gebruik index.html als bestandsnaam voor deze 
pagina. 

B. Maak een geschikte datasource voor je database. 

C. Maak een view met de naam StorePurchases die de volgende kolommen heeft: 
StoreName, City, Country, E-mail, Contact, Date, Description, Category en 
PriceUSD. 

D. Maak een PHP-pagina voor het weergeven van StorePurchases. Demonstreer 
met behulp van je voorbeelddatabase dat je pagina werkt. 

E. Maak twee HTML/PHP-pagina's voor het invoeren van een datumwaarde 
AsOfDate en het weergeven van rijen van StorePurchases voor aankopen met 
een datum later dan of gelijk aan AsOfDate. Demonstreer met behulp van je 
voorbeelddatabase dat je pagina's werken. 

EF. _ Schrijf twee HTML/PHP-pagina’s voor het aannemen van Country en Category 
en het weergeven van rijen van StorePurchases die de ingevoerde waarden voor 
Country en Category bevatten. Demonstreer met behulp van je voorbeelddata- 
base dat je pagina’s werken. 

G. Schrijf een opgeslagen procedure die waarden aanneemt voor PurchaselD en 
NewPriceUSD en die de waarde van PriceUSD instelt op NewPriceUSD voor de 
rij met de opgegeven waarde van PurchaselD. Lever een foutmelding als er geen 
rij is met de opgegeven waarde van PurchaselD. Demonstreer met behulp van je 
voorbeelddatabase dat je opgeslagen procedure werkt. 

H. Schrijf een PHP-pagina voor het aanroepen van de opgeslagen procedure die je 
in G hebt gemaakt. Demonstreer met behulp van je voorbeelddatabase dat je pa- 
gina werkt. 
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Hoofdstuk 12 
Databaseverwerking met XML 


Dit hoofdstuk gaat over een van de meest belangrijke, zo niet het belangrijkste onder- 
werp uit de hedendaagse informatietechnologie: databaseverwerking en document- 
verwerking. Deze twee gebieden zijn meer dan twintig jaar lang onafhankelijk van 
elkaar ontwikkeld. Ze zijn na de opkomst van internet echter op elkaar gestoten. Het 
effect daarvan wordt nog steeds onderzocht en er verschijnen vrijwel elke maand nieu- 


we producten, nieuwe productkenmerken, nieuwe technische standaarden en nieuwe 
ontwikkelingstechnieken. 
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12.1 Het belang van XML 


Databaseverwerking en documentverwerking hebben elkaar nodig. Database- 
verwerking heeft documentverwerking nodig voor het overdragen van database- 
views. Documentverwerking heeft databaseverwerking nodig voor het opslaan van 
en werken met gegevens. Hoewel deze technieken van elkaar afhankelijk zijn, was 
de opkomst van internet nodig om die noodzaak duidelijk te maken. Toen er websites 
ontstonden, wilden organisaties internettechniek gebruiken voor het weergeven en 
bijwerken van gegevens uit organisatiedatabases. Webontwikkelaars begonnen toen 
serieus geïnteresseerd te raken in SQL, databaseprestaties, databasebeveiliging en 
andere aspecten van databases. 

De gemeenschappen van database- en documentverwerking ontmoetten elkaar 
aan het begin van de jaren negentig en hun werk resulteerde in een reeks standaar- 
den voor een taal die XML of Extensible Markup Language wordt genoemd. Naar- 
mate de XM L-standaarden zich ontwikkelden, werd het in feite duidelijk dat de beide 
gemeenschappen al vele jaren aan verschillende aspecten van hetzelfde probleem 
hadden gewerkt. Ze gebruikten zelfs dezelfde termen, maar met een verschillen- 
de betekenis. Je zult later in dit hoofdstuk zien hoe de term schema wordt gebruikt 
in XML, voor een concept dat compleet verschilt van het gebruik van schema in de 
databasewereld. 

XML levert een gestandaardiseerde, maar toch flexibele manier voor het be- 
schrijven van de inhoud van documenten. Het kan als zodanig ook worden gebruikt 
voor het beschrijven van willekeurige databaseviews en op een gestandaardiseerde 
manier. 

XML-documenten kunnen automatisch worden gegenereerd vanuit database- 
gegevens als ze samen met de standaard XML Schema worden gebruikt. Er kunnen 
ook automatisch databasegegevens uit XML-documenten worden geëxtraheerd. En 
dat is nog lang niet alles. Er zijn ook gestandaardiseerde manieren om te definiëren 
hoe componenten van documenten aan componenten van het databaseschema wor- 
den gekoppeld en omgekeerd. 

De rest van de computergemeenschap begon ondertussen ook in XML geïnteres- 
seerd te raken. SOAP (Simple Object Access Protocol), werd als een op XML geba- 
seerde standaard gedefinieerd voor het leveren van externe services over internet. 
SOAP nam in eerste instantie aan dat http gebruikt zou worden als transportpro- 
tocol, maar deze aanname werd verworpen toen Microsoft, IBM, Oracle en andere 
grote bedrijven hun krachten bundelden voor het ondersteunen van deze standaard. 
SOAP werd algemener gemaakt, tot een standaardprotocol voor het versturen van 
berichten van elk type en elk protocol. Deze wijziging betekende dat SOAP geen 
‘simple object access protocol’ meer was. SOAP is nu dan ook geen afkorting meer, 
maar gewoon een naam. 

Tegenwoordig heeft XML veel doeleinden. Een van de belangrijkste is het gebruik 
als een gestandaardiseerde manier voor verwerking over internet. XML speelt een 
centrale rol in het .NET-initiatief van Microsoft. Bill Gates noemde XML in 2001 de 
‘lingua franca van het internettijdperk’. 
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We beginnen deze toelichting van XML door te beschrijven hoe XML wordt gebruikt 
voor het weergeven van websites. Je zult echter zien dat XML voor veel meer doel- 
einden te gebruiken is. Het weergeven van websites is misschien wel het minst be- 
langrijke doeleinde van XML. We beginnen hiermee, omdat het een makkelijke 
manier is voor het introduceren van XML-documenten. We leggen vervolgens de 
standaard XML Schema uit en bespreken hoe deze standaard wordt gebruikt voor 
databaseverwerking. 

Denk er tijdens het lezen van dit hoofdstuk aan dat dit gebied zich aan het voor- 
front van de moderne databaseverwerking bevindt. Standaarden, producten en mo- 
gelijkheden van producten veranderen voortdurend. Je kunt op de hoogte blijven 
van deze wijzigingen via sites als www.w3c.org, www.xml.org, msdn.microsoft.com, 
www.oracle.com, www.ibm.com en www.mysql.com. Het zelf leren en bijhouden van 
de ontwikkelingen van XML en databaseverwerking, is een van de beste manieren 
waarop je je kunt voorbereiden op een succesvolle carrière in databaseverwerking. 


12.2 XML als opmaaktaal 


XML is om verschillende redenen een aanzienlijk betere opmaaktaal dan HTML. 
Ten eerste hebben de ontwikkelaars van XML een duidelijke scheiding aangebracht 
tussen de structuur, de inhoud en de materialisatie van een document. XML heeft 
voorzieningen voor het omgaan met elk onderdeel en deze hebben een dusdanige 
aard dat ze niet door elkaar gehaald kunnen worden, zoals dat bij HTML wel het ge- 
val is. 

XML is weliswaar gestandaardiseerd maar de standaard kan, zoals de naam al 
zegt, door ontwikkelaars worden uitgebreid. Je zit met XML niet vast aan een be- 
perkte verzameling elementen zoals <title>, <hr> en <p>. Je kunt in plaats daarvan 
je eigen elementen maken. 

Ten derde elimineert XML de inconsequente manier voor het gebruik van tags 
die mogelijk (en populair) zijn met HTML. Kijk eens naar de volgende HTML als 
voorbeeld: 


<h2>Hallo wereld!</h2> 


De tag <h2> kan weliswaar worden gebruikt om een kop van het tweede niveau te 
markeren, maar kan ook voor veel andere dingen worden gebruikt. Bijvoorbeeld om 
er simpelweg voor te zorgen dat ‘Hallo wereld!’ in een bepaalde puntgrootte, dikte 
en kleur wordt weergegeven. Omdat een tag op zoveel verschillende manieren kan 
worden gebruikt, kunnen we er niet op vertrouwen dat tags de echte structuur van 
een HTML-pagina aangeven. Het gebruik van tags is te willekeurig, <h2> kan zowel 
een kop betekenen als helemaal niets. 

Zoals je zult zien, kan de structuur van een XML-document formeel worden 
gedefinieerd. Tags worden gedefinieerd in relatie tot elkaar. Als we in XML de tag 
<straat> zien, dan weten we exact welke gegevens we hebben, waar deze tag thuis- 
hoort en hoe deze in de documentstructuur aan andere tags is gerelateerd. 
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12.2.1 XML-documenttypen declareren 

Je ziet een voorbeeld van een XML-document in Figuur r2-1. Je ziet dat het document 
twee secties heeft. De eerste sectie definieert de structuur van het document — deze 
sectie wordt de Document Type Declaration of DTD genoemd. De tweede sectie be- 
vat de gegevens. 

De DTD begint met het woord DOCTYPE en specificeert de naam van dit type 
document — in dit geval ‘Customer’. Op de volgende regel staat de inhoud van Cus- 
tomer, die bestaat uit twee groepen: CustomerName en Address. De CustomerNa- 
me bestaat uit twee elementen: FirstName en LastName. Voornaam en achternaam 
zijn gedefinieerd als #PCDATA, wat inhoudt dat het strings met tekstgegevens zijn. 
Daarna wordt gedefinieerd dat het adreselement uit vier elementen bestaat: Street, 
City, State en Zip. Deze worden ook alle gedefinieerd als tekstgegevens. Het pluste- 
ken na Street geeft aan dat één waarde is vereist en dat meer waarden mogelijk zijn. 


<?xml version="1,0" encoding="U[F-8"?> 

SIDOCTYPE Customer [ 
SIELEMENT Customer (CustomerName, Address) 
STELEMENT Customerkame (FirstName, LastName)> 
SIELEMENT FirstName (GPCDATA)> 
<IELEMENT LastName (G#PCDATA) 
SIELEMENT Address (Streett, City, State, Zip)> 


SIELEMENT Street (H##PCDATA)> 
SIELEMENT City ({PCDATA)> 
SIELEMENT State ({#PCDATA)> 
STELEMENT Zip (A#PCDATA)> 

D 


<Customer> 


<CustomerName> 
<FirstName>deffery&/FirstName> 
<LastName>Janes</LastName> 

</CustomerName> 

SAddress> 
<Street>123 W. Elm St.</Street> 
<City>Renton</City> 
<State>WA</State> 
<Zip>98055</Zip> 

</Address> 

</Customer> 


Figuur 12-1 XML-document met interne DTD 


De indeling van de gegevens van Customer die je in de onderste helft van Figuur 
12-1 ziet, houdt zich aan de DTD in de bovenste helft — er wordt daarom gezegd dat 
dit document een type-valid XML-document is. Het zou een not-type-valid document 
zijn als het zich niet aan de DTD zou houden. Documenten die not-type-valid zijn, 
kunnen nog steeds goede XML zijn — ze zijn alleen geen geldige instanties van hun 
type. Het document in Figuur 12-1 zou bijvoorbeeld nog steeds een geldig XML- 
document zijn als het twee plaatselementen zou bevatten. Het zou dan echter niet- 
type-valid zijn. 
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DTD’s zijn weliswaar vrijwel altijd wenselijk, maar ze zijn niet verplicht in XML- 
documenten. Documenten zonder DTD zijn per definitie not-type-valid, want er is 
geen type waarmee ze te controleren zijn. 

De DTD hoeft niet in het document zelf te staan. Figuur 12-2 toont een klant- 
document waarin de DTD wordt verkregen uit het bestand C:\inetpub\wwwroot\ 
DBP\VRG\CustomerList.dtd. De DTD staat in dit geval op de computer waarop dit 
document is opgeslagen. Via URL-webadressen kan ook naar DTD's worden verwe- 
zen. Het voordeel van het extern opslaan van de DTD is dat veel documenten gecon- 
troleerd kunnen worden via dezelfde DTD. 

ND 


<?xml version="1.0" encoding="UTF-8"2> 


<IDOCTYPE CustomerList SYSTEM “C:\inetpub\wwwroot\DBPAVRG\ e Akaloaus cd 


Customerlist.dtd"> 
<CustomerLi 


Customer> 


FarstName> 


/LastName> 


Tumbleweed Lane</Street> 


>tate» 
<Zip>81201</Zip> 
</Address> 
Ns / (c iIStomer / 
</CustomerList> 


Figuur 12-2 XML-document met externe DTO 


De maker van een DTD mag alle willekeurige gewenste elementen kiezen. XML- 
documenten kunnen dus worden uitgebreid, maar op een gestandaardiseerde, flexi- 
bele manier. 


12.2.2 XML-documenten materialiseren met XSLT 

Het XML-document in Figuur 12-1 laat zowel de structuur als de inhoud van het do- 
cument zien. Er wordt echter nergens in het document aangegeven hoe het moet 
worden gematerialiseerd. De ontwerpers van XML hebben de structuur, de inhoud 
en de vormgeving streng van elkaar gescheiden. De populairste manier voor het 
materialiseren van XML-documenten is het gebruik van XSLT. XSLT, of de Exten- 
sible Style Language: Transformations, is een krachtige en robuuste transformatie- 
taal. Deze taal kan worden gebruikt voor het materialiseren van XML-documenten in 
HTML en voor allerlei andere doeleinden. XSLT wordt vaak gebruikt voor het trans- 
formeren van een XML-document in de ene indeling naar een XML-document in 
een andere indeling. Een bedrijf kan XSLT bijvoorbeeld gebruiken voor het transfor- 
meren van een orderdocument met hun eigen vormgeving naar een overeenkomstig 
XML-orderdocument in de indeling van de klant. Er zijn nog veel meer mogelijk- 
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heden en functies van XSIT, die we hier niet kunnen bespreken. Zie www.w3.org 
voor meer informatie over dit onderwerp. 


XSLT is een declaratieve transformatietaal. De taal is declaratief omdat je geen 
procedure opgeeft voor het materialiseren van elementen van het document, maar 
een verzameling regels maakt die bepaalt hoe het document gematerialiseerd moet 


worden. De taal is transformerend, omdat deze het invoerdocument in een ander 
document transformeert. 


<?xml version="1.0" encoding="UTF-8"?5 
<IELEMENT CustomerList (Customer+)2 
SIELEMENT Customer (CustomerWame, Address)> 
<IELEMENT CustomerName (Firsthame, 
SLELEMENT FirstName (#PCDATA)> 
SIELEMENT LastName (A#PCDATA)2 
<IELEMENT Address (Streett, City, State, 
<IELEMENT Street (#PCDATA)> 

<IELEMENT City (4#HPCDATA)> 

SIELEMENT State (#PCDATA)> 

SIELEMENT Zip (APCDATA)> 


(2) 


LastName)> 


Zip)> 


<?xml version="1.0" encoding="UTF-8"?2> 
<IDOCTYPE CustomerList SYSTEM “C:\inetpub\wwwroot\DBP\VRG\CustomerList 
<?xml-stylesheet type="text/xsl" href="http://localhost/DBP/VRG/ 
CustomerListStylesheet.xs1"?2> 
<CustomerList> 
<Customer> 
<CustomerName> 
<FirstName>deffery</FirstName> 
<LastName>Janes</LastName> 
</CustomerName> 
<Address> 
<Street>123 W. Elm St.</Street> 
<City>Renton</City> 
<State>WA</State> 
<Zip>98055</Zip> 
</Address> 
</Customer> 
<Customer> 
<CustomerName> 
<FirstName>David</FirstName> 
<LastName>Smith</LastName> 
</CustomerName> 
<Address> 
<Street>813 Tumbleweed Lane</Street> 
<City>Durango</City> 
<State>C0</State> 
<Zip>81201</Zip> 
</Address> 
</Customerd 
</CustomerList> 


(b) 


Figuur 12-3 Customerlist DTD en voorbeelddocument 


„dtd” 


458 


DATABASEVERWERKING MET XML 


Figuur 12-3(a) toont een DTD voor een document met een lijst van klanten. Figuur 
12-3(b) toont een document dat type-valid is voor deze DTD. Het DOCTYPE-state- 
ment in Figuur 12-3(b) verwijst naar een bestand dat de in Figuur 12-3(a) getoonde 
DTD bevat. Het volgende statement in het XML-document bevat de verwijzing naar 
een ander document, dat stylesheet wordt genoemd (en dat je ziet in Figuur 12-4). 
XSLT gebruikt stylesheets om aan te geven hoe de elementen van het XML-document 


<title istomer ESty heet</title 


tit] 
ú { t Hi nter lor el) 
body {font-family:zartel, sans-serif: font-size:l2pt;: 
background-color:ijFFFEFF) 
div.customername (font-weiaht:bold; 
background-color:i#3399FF:color:iFFFFFF: 
padding 
div.customerdata (font-siz pt: font :bolds; 


backqround-color 


000000; 
marqin-left:20px: margin-bottom:20px| 
p.footer (text-align:center| 

</style> 
</head> 


<body> 


View Ridge Gallery Customer List 
</hl> 
<hr/ 
<xslrfor-each select="CustomerList/Customer"> 
<div class="customername”> 
<xsl:value-of select="CustomerName/LastName"/>, 
Cxsl:value-of select="CustomerName/firstName"/> 
</div> 
CHE AD 
<div class="customerdata”> 
for-each select="Address/Street"> 
<xsl:value-of select="nodel }"/D 
</xsl:for-each> 
Kd ol > 
<xsl:value-of select="Address/City"/>, 
<xsl:value-of select="Address/State”"/D 
<br /2 
<xsl:value-of select="Address/Zip"/D 
</div> 
</xsl:for-each> 
<hr /2 
<p class="footer"> 
<a href="../VRG/index.html "> 
Return to View Riage Gallery Home Page 
</a> k 
</p> 
<hr /2 
</body> 
</html> 
</xsl:template> 
</xsl:stylesheetò 


Figuur 12-4 CustomerlistStylesheet.xsl 
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in een andere indeling moeten worden getransformeerd — deze elementen zullen 
het in een HTM L-document omzetten dat acceptabel is voor een browser. 

De XSLT-processor kopieert de elementen van de stylesheet tot er een opdracht 
wordt gevonden van de vorm {item, actie}. Als er een dergelijke opdracht is gevon- 
den, zal de XSLT-processor naar een instantie van het opgegeven item zoeken en, 
als een dergelijke instantie wordt gevonden, de opgegeven actie uitvoeren. Komt de 
XSLT-processor bijvoorbeeld: 


<xsl:for-each select="Customerlist/Customer"> 


tegen, dan zal de processor in het document zoeken naar een element met de naam 
CustomerList. Als dat element is gevonden, dan zal de processor binnen het element 
CustomerList verder zoeken naar een element met de naam Customer. Wordt er een 
match gevonden, dan worden de opgegeven acties uitgevoerd in de lus die eindigt 
met </xsl:for-each> (in het onderste deel van de stylesheet). 

In deze lus worden stijlen ingesteld voor elk element in het document Customer- 
List. In Figuur 12-5 zie je het resultaat van het toepassen van de stylesheet uit Figuur 


12-4 op het document in Figuur 12-3(b). Lees het document en de stylesheet eens 
door en kijk hoe het resultaat wordt gegenereerd. 


ahan 


| 49 CustomerlistStytesheet - Windows Internet Explorer 


es CE 

De Îe hep tocathost enrrG Conomer. Document omt Tae Tx 2D oee 2 vl 
Í 

| cg Favorites | {> EJ Welcometolstemebapt. (B sogereitens gee 5 | 
& CustomnerListStylesheet MP v TJ + - mm v Pager Safetyv Toolkv dv í 


nde: NN 
(|_ 123W. Emst | 
| Renton, WA 
38055 


813 Tumbleweed Lano Í 
Durango, CO 
81201 


| 
| 
Retum to View Ridge Gallery Home Page í 


/ Trusted sites | Protected Mode: Off ar Kox | 
Bretten 


Figuur 12-5 HTML-resultaat van de toepassing van een stylesheet 
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XSLT-processors zijn contextgevoelig — elk statement wordt geëvalueerd in de con- 
text van de gevonden match. Het volgende statement: 


<xsl-value-of select= “CustomerName/LastName"> 
werkt dus in de context van CustomerList/Customer. Het is niet nodig: 
Sxsl:select= "CustomerList/Customer/CustomerName/LastName">/ 


te schrijven, want de context is CustomerList/Customer. Er zou in feite niets worden 
gevonden als we de select op de tweede manier zouden schrijven. Er zal ook geen 
match worden gevonden voor <xsl:select= “LastName”>/, want de achternaam komt 
alleen voor binnen de context CustomerList/Customer/CustomerName, niet in de 
context Customer List/Customer. 


Opmerking 

Oe aard van XSLT-processing is: doe telkens dit, als je dat vindt. Het document in Figuur 12-4 zegt dus: doe 
het volgende voor tedere klant die je vindt onder de tag klantenlijst: produceer een HTML <div> … </div> 
sectie, gevolgd door nog wat HTML met de waarde die je in het document vindt voor CustomerName/ 
LastName. Produceer vervolgens nog wat HTML, evenals de waarde die je vindt voor CustomerName/ 
LastName. Genereer daarna wat HTML voor elk(e) adres/straat die je vindt, samen met de waarde voor 
adres/straat die je net hebt gevonden. Enzovoort. 

XSL kan een willekeurige uitvoer leveren. Het zou evengoed Russisch of Perzisch kunnen schrijven — 

of wiskundige formules — in plaats van HTML te produceren. XSL is gewoon een voorziening voor het 
omzetten van gestructureerde documenten, zoals XML-documenten. 


Deze contextgevoeligheid verklaart waarom het volgende statement nodig is (mid- 
den in de stylesheet): 


<xsl:value-of select= “node()"/> 


De context is, op de plaats van dit statement, gelijk aan CustomerList/Customer/ 
Address/Street. De huidige node is dus het element Street en deze expressie geeft 
aan dat de waarde van deze node moet worden geproduceerd. 

Merk ook op dat er een kleine transformatie wordt uitgevoerd door de stylesheet. 
FirstName werd in het originele document gevolgd door LastName, maar in de uit- 
voer is dat omgekeerd. 

Browsers hebben een ingebouwde XSLT-processor. Je hoeft alleen het XML-docu- 
ment aan de browser te leveren — de browser zal de stylesheet vinden en deze voor je 
op het document toepassen. Dat levert een resultaat op als in Figuur 12-5. 


12.3 XML Schema 


DTD's waren de eerste poging van de XML-gemeenschap een taal te ontwikkelen 
voor het specificeren van de documentstructuur. DTD's werken maar hebben wel 
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een aantal beperkingen — en DTD's zelf zijn helaas geen XML-documenten. Het 
W3C-comité heeft een andere specificatietaal gedefinieerd om deze problemen te 
corrigeren. Deze taal heet XML Schema. Dit is tegenwoordig de voorkeursmethode 
voor het definiëren van de documentstructuur. 

XML Schema's zijn XML-documenten. Dat houdt in dat je dezelfde taal kunt ge- 
bruiken voor het definiëren van een XML Schema als voor het definiëren van welk 
ander XML-document dan ook. Het betekent ook dat je een XML Schema-document 
kunt controleren via zijn schema, net als met elk ander XML-document. 

Als je dit hoofdstuk kunt volgen, zul je je realiseren dat we hier een kip-of-ei- 
kwestie hebben. Als XML Schema-documenten zelf XML-documenten zijn, welk 
document bestaat er dan dat te gebruiken is als het schema van alle schema's? Er 
bestaat zo’n document — je vindt de moeder van alle schema's op www.w3.org. Alle 
XML Schema's worden gecontroleerd via dit document. 


Opmerking 

Het valideren van XML Schema's vereist dat je op twee metaniveaus denkt. Denk eraan, om te begrijpen 
waarom dat zo is, dat metadata gegevens over gegevens zijn. De uitspraak Customer bevat de kolom 
CustomerLastName Char(25) behoort tot de metadata. Als we dat idee uitbreiden, dan bevat de uitspraak 


sQL heeft een datatype Char(n) voor het definiëren van tekstgegevens met lengte n gegevens over 
metadata, oftewel meta-metadata. 


XML heeft dezelfde metaniveaus. Een XML-document heeft een structuur die wordt gedefinieerd door een 
XML Schema-document. Een XML Schema-document bevat metadata, want dit heeft gegevens over de 
structuur van andere XML-documenten. Een XML Schema heeft echter zelf ook een structuur, die wordt 


gedefinieerd door een ander XML Schema. Dat andere XML Schema-document bevat gegevens over 
metadata, oftewel meta-metadata. 


Je kunt een programma gebruiken voor het valideren van een XML-document. Je kunt elk willekeurig 
XML-document valideren aan de hand van het XML Schema-document ervan. Dat proces blijft precies 


hetzelfde, ongeacht of je een XML-document valideert of een XML Schema-document, of een document 
op een willekeurig ander niveau. 


XML Schema is een uitgebreid en ingewikkeld onderwerp. Er zijn tientallen dikke 
boeken geschreven die alleen over dit onderwerp gaan. Je zult begrijpen dat we niet 
in staat zijn zelfs maar de belangrijkste aspecten van XML Schema in dit hoofdstuk 
te bespreken. We concentreren ons in plaats daarvan op een paar basistermen en 
-concepten en laten je zien hoe deze termen en concepten gebruikt worden voor 


databaseverwerking. Je zult na deze inleiding in staat zijn zelf meer over dit onder- 
werp te leren. 


12.3.1 XML Schema's valideren 

Figuur 12-6 toont een eenvoudig XML Schema-document dat kan worden gebruikt 
voor het representeren van een enkele rij van de tabel WORK van galerie View Ridge. 
De eerste regel geeft aan welk schema moet worden gebruikt voor het valideren van 
dit document. Het is een XML Schema-document en het wordt daarom gecontro- 
leerd aan de hand van de moeder van alle schema's op www.w3.org. Deze verwij- 
zing wordt in alle XML Schema's van elk bedrijf waar ook ter wereld gebruikt. Het 
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verwijzingsadres wordt overigens alleen gebruikt voor identificatiedoeleinden. Dit 
schema wordt zo vaak gebruikt dat de meeste programma's voor het valideren van 
schema's er een eigen ingebouwde kopie van hebben. 


tribute name="ArtSt 
nplexType> 
</xS:eltement 


hema > 


Figuur 12-6 Gebruik van een XML Schema 


Het eerste statement definieert niet alleen welk document er gebruikt moet wor- 
den voor het valideren, maar zet ook een gelabelde namespace op. Namespaces 
vormen een ingewikkeld onderwerp op zichzelf. We leggen hier alleen uit hoe de la- 
bels gebruikt worden en gaan verder niet op dit onderwerp in. Het eerste statement 
definieert xs met de expressie xmins:xs. Het eerste deel van deze expressie is een 
afkorting van xml namespace, het tweede deel definieert het label xs. De expressie 
xs:complexType vertelt het validerende programma dat het in de namespace met de 
naam xs (dat hier wordt gedefinieerd door www.w3.org/20o1/Schema) moet zoeken 
naar de definitie van de term complex Type. 

De ontwerper van het document kan de naam van het label kiezen. Je zou xmlns:xs 
in xmlns:mijnlabel kunnen veranderen. Je zou mijnlabel dan instellen om naar het 
w3-document te verwijzen. Documenten kunnen meer namespaces hebben, maar 
dat onderwerp valt buiten het bereik van deze bespreking. 


12.3.2 Elementen en attributen 


Je ziet in Figuur 12-6 dat schema's bestaan uit elementen en attributen. Er zijn twee 
soorten elementen: eenvoudige en complexe. Eenvoudige elementen bevatten een 
enkel gegeven. De elementen LastName, FirstName, Nationality, DateOfBirth en 
DateDeceased in Figuur 12-6 zijn allemaal eenvoudige elementen. 

Complexe elementen bevatten andere elementen, die zelf eenvoudig of complex 
kunnen zijn. Het element Artist in Figuur 12-6 is een complexType. Het bevat een 
reeks van vijf eenvoudige elementen: LastName, FirstName, Nationality, DateOfBirth 
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en DateDeceased. Je zult later voorbeelden zien van complexe typen die andere com- 
plexe typen bevatten. 

Complexe typen kunnen attributen hebben. Figuur 12-6 definieert het attribuut 
ArtStyle. De maker van een XML-document gebruikt dit attribuut voor het opgeven 
van een kenmerk van een kunstenaar — in dit geval zijn of haar stijl. Het voorbeeld- 


document in Figuur 12-7 specificeert de ArtStyle voor deze kunstenaar (Miro) als 
Modern. 


<?xml version="1.0" encoding="UTF-8"7> 
<Artist xminssxsie"http: //www.w3.0 1/XHL nstane r € T i 
:\inetpuD\wwwroot\DBP\VRG\VRG-ARTIST-001.xsd” ArtStyle="Modern” 
<LastName>Miro</LastHame> 
<FirstName>Joang/FirstName> 
<kationality>Spanish</Nationality> 


<DateOfBirth>1893</DateOfBirtn> 
<DateDeceased>1983C/DateDeceased> 
CfArtist> 


Figuur 12-7 Voorbeelddocument dat voldoet aan het schema van Figuur 12-6 


Figuur 12-7 laat een XML-document zien dat voldoet aan het in Figuur 12-6 getoon- 
de schema. Merk op dat de waarde van het attribuut ArtStyle wordt opgegeven met 
de kop van het element Artist. Bovendien wordt er een namespace xsi gedefinieerd. 
Deze namespace wordt maar één keer gebruikt, namelijk voor het attribuut no- 
NamespaceSchemaLocation. Maak je niet druk over de naam van dit attribuut — dit 
is gewoon een manier waarop de XML-parser kan worden verteld waar deze het XML 
Schema kan vinden voor dit document. Concentreer je op de relatie tussen de struc 
tuur van het document en de beschrijving in het XML Schema. 


Opmerking 

Elementen en attributen dragen beide gegevens over. Je vraagt je daarom misschien af wanneer je 

het ene moet gebruiken en wanneer het andere. Je kunt de volgende algemene regel gebruiken voor 
database/XML-applicaties: gebruik elementen voor het opslaan van gegevens en gebruik attributen voor 
het opslaan van metadata. Definieer bijvoorbeeld een element ItemPrijs voor het opslaan van de waarde 


van een prijs en definieer een attribuut Valuta voor het opslaan van het valutatype van die prijs, zoals 
Amerikaanse of Australische dollars of euro's. 


De XML-standaarden vereisen op geen enkele manier dat elementen en attributen op deze manier 
worden gebruikt. Het is alleen een zaak van stijl en we zullen later laten zien hoe we SQL Server alle 
kolomwaarden in attributen of in elementen kunnen laten plaatsen. We kunnen sommige kolommen ook 
in attributen en andere in elementen laten plaatsen. Deze beslissingen worden dus niet geregeld door 
een XML-standaard maar zijn slechts een ontwerpkeuze. 


De kardinaliteit van eenvoudige en complexe elementen is standaard 1.1, wat be- 
tekent dat er een enkele waarde is vereist en dat er niet meer dan één waarde mag 
worden opgegeven. De minOccurs=“o” in het schema in Figuur 12-6 geeft aan dat 
de defaultwaarden vervangen worden voor DateOfBirth en DateDeceased. Deze hoe- 
ven geen waarde te hebben. Dat lijkt op de constraint NULL in de definitie van een 
SQL-schema. 
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Figuur 12-8 toont een grafische representatie van het XML Schema. Zo'n diagram 
maakt het makkelijker te begrijpen wat het XML Schema inhoudt. Merk op dat in dit 
diagram de vereiste elementen (NOT NULL in SQL) met een ononderbroken lijn en 
de niet-vereiste elementen (NULL in SQL) met een stippellijn worden weergegeven. 


“LastName 


Figuur 12-8 Grafische weergave van het XML Schema 


Het diagram in Figuur 12-8 is getekend met Altova's XMLSpy XML editing tool, zie 
http://www.altova.com. 


12.3.3 Platte versus gestructureerde schema’s 

Figuur 12-9 laat een XML Schema zien dat de kolommen representeert van de 
tabel CUSTOMER van de database van galerie View Ridge. Je ziet dat Country en 
E-mailAddress optioneel zijn, maar dat alle andere elementen vereist zijn. 


rqg/2001/XMLSchema” elementFormDefault="qualified" attribut 


3 xmIns:xs="N 
ult="unqualifie 
ent name="Custom 
nnotation> 
<xs:documentation> 
This ís t ML Schema for the VRG CUSTOMER table 
</xs:documentation>d 
</xszännotation> 
<xs:complexlype> 
(xs:sequenced 
<xs:element name="CustomerID” type="xs:int"/> 
<xs:element name="LastName” type="xs:string"/> 
<xs:element name="FirstName" type="xs:string"/> 
<xs:element name="Street" type="xs:string” minOccurs="0"/> 
<xs:element name="City" type="xs:string” minOecurs="0"/D 
<xs:element name="State” type="xs:string” min0ccurs="0"/> 
<xs:element name="ZipPostalCode” type="xs:string” 
minOecurs="0"/> 
<xs:element name="Country” type="xs:string" minOccurs="0"/D 
<xsrelement name="AreaCode” type="xs:string” minOccurs="0"/> 
<xs:element name="PhoneNumbder” type="xs:string” 
minOccurs="0"/> 
<xs:element name="EmailAddress” type="xs:string” 
min0ccurs="0"/> 
</xs:sequenced 
</xs:complexType> 
</xs:elementò 
</xs:schemad 


Figuur 12-9 Plat XML Schema 
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Het document in Figuur 12-10 bevat een van de rijen van de tabel CUSTOMER. 


<?xml version="1.0" encoding="UIF-8"2> 
<Customer xmlns:asi="http://uww.w3.0org/2001/XMLSchema-instance” xsi:noNamespaceSchemato 
cation="C:\inetpub\wwwroot\DBP\VRG\DBP-ell-Figure-12-07-A.xsd"> 

<CustomerID>10004/CustomerlD> 

<LastName>Janes{/LastHName> 

<FirstName>deffery4/FirstName> 

<Street>123 W. Elm St.</Street 

<City>Renton</City> 

<State>WA</State> 

<ZipPostalCode>98055</4ipPostalCode, 

<Country>USA</Country> 

CAreaCode>A25/AreaCade> 

<PhoneNumber>543-2345</Phoneumber> 

<EmailAddress>Jeffery.Janes@somewhere.com</EmailAddress> 
</Customer> 


Figuur 12-10 Document dat voldoet aan het schema van Figuur 12-9 


Een XML Schema zoals dat in Figuur 12-9 wordt soms wel een plat schema ge- 
noemd, omdat alle elementen op hetzelfde niveau staan. Figuur 12-11 laat grafisch 
zien waarom dit schema plat wordt genoemd. Merk ook op dat de optionele elemen- 
ten worden weergegeven in met stippellijnen getekende vakken. 


“CustomeriD 


BESS XML Schemz For : (rennen 5 
MER zanie t-J"ZipPostalCode ! 
r- ha “Country à 


Figuur 12-11 Diagram bij het schema van Figuur 12-9 
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Als je even over deze elementen nadenkt, zul je je realiseren dat er iets over hun se- 
mantiek is weggelaten. Alle elementen van de groep (Street, City, State, ZipPostal- 
Code, Country} maken deel uit van het element Address en alle elementen van de 
groep (AreaCode, PhoneNumber} maken deel uit van het element Phone. Zoals je 
weet worden in het relationele model alle kolommen op dezelfde manier behandeld 
— het is niet mogelijk dergelijke samenstellingen te representeren. 

XML biedt echter wel een manier voor het representeren van dergelijke groepen. 
Het schema in Figuur 12-12 structureert de juiste kolommen in een complexType 
Address en andere kolommen in een complexType Phone. 


xm *_encoding="UIf 2 
chema xmlns:xs="htEp://www.w3.0rg/2001/XMLSchema" 
entFormDefault="qualified” attributeFormDefault="unqualified"> 
Ju n 
Te I ina 
1 } [ en ring” 

1 ì Ne tring 
name="ZipPostalCode” type="xs:string”/> 
name="Country” type="xs:string” min0ccurs="0"/> 

juenc 
cor xTyp 
( ì “Phor 
Ô ment name="AreaCode” type="xs:string”/> 


ament name="PhoneNumbder” type="xs:string"/> 
s:sequence, 
Xs -COmplexT ype> 


element name="Customer"> 


is the structured XML Schema for the VRG CUSTOMER table 


jocumentation 


name="CustomerID" type="xs:int"/> 
name="Lasthame" type string”/> 
name="FirstName" type="xs:string"/> 


“Address” type="AddressType" 


element 
min0Occurs 
<xsrelement name="Phone" type="PhoneType” min0ccurs="0"/D 
<xs:element name="EmailAddress" type="xs:string” 
minOccurs="0"/D 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:schema> 


Figuur 12-12 Gestructureerd XML Schema 


Dergelijke schema's worden soms gestructureerde schema's genoemd, omdat ze 
structuur toevoegen aan tabelkolommen. Een dergelijk model geeft beter weer wat 
de gebruikers bedoelen en is daarom superieur aan het relationele model, gezien 
vanuit een omschrijvend gezichtspunt. 
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Een grafische weergave van dit schema zie je in Figuur 12-13. 


=CustomerlD 


“LastName 


FirstName 


ee | 


t-2S Country 


eeens. a 


-> EmailAddress ! 


Figuur 12-13 Grafische weergave van het schema in Figuur 12-12 


Figuur 12-14 toont een XML-document voor een van de rijen van CUSTOMER, die 
in deze indeling is uitgedrukt. 


12.3.4 Globale elementen 
Stel dat we XML Schema willen gebruiken voor het weergeven van een document dat 
de in Figuur 12-12 getoonde klantengegevens uitbreidt met de aan die klant toege- 
kende verkoper. Stel verder dat klanten en verkopers beiden adres- en telefoongege- 
vens hebben. We kunnen deze nieuwe klantenstructuur representeren met behulp 
van de tot dusver getoonde technieken, maar we dupliceren in dat geval de definitie 
van Phone en Address. 

We maken ons in de relationele wereld druk over het dupliceren van gegevens. 
We doen dat niet zozeer vanwege de verspilde bestandsruimte, maar voornamelijk 
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tance” xSsi:noNamespace 
15 


Figuur 12-14 XML-document dat voldoet aan het schema van Figuur 12-12 


omdat er altijd een kans bestaat dat er niet-consequente gegevens optreden als de 
ene kopie van de gegevens wel en de andere kopie niet wordt gewijzigd. De mensen 
uit de wereld van de documentverwerking maken zich ook druk over dubbele defini- 
ties van elementen, omdat er altijd een kans bestaat dat er niet-consequente defini- 
ties optreden als de ene definitie wel en de andere niet wordt gewijzigd. 

We kunnen de gedupliceerde definitie verwijderen door het betreffende element 
globaal te declareren en dan opnieuw te gebruiken. De adresgroep in Figuur 12-15 is 
gedefinieerd als het globale element AddressType en de telefoongroep als het globale 
element PhoneType. Dit zijn volgens de standaard XML Schema globale elementen, 
omdat ze in het bovenste niveau van het schema staan. 

Als je Figuur 12-15 nader bekijkt, zie je dat Customer en SalesPerson in Custo- 
mer beide de globale definities AddressType en PhoneType gebruiken. Er wordt naar 
deze definities verwezen met een notatie zoals type="AddressType”. Het gebruik van 
deze globale definities betekent dat de definities van Customer en Salesperson de 
wijzigingen beide zullen erven als PhoneType of AddressType worden veranderd. 

Nog een andere wijziging in deze figuur is dat de kardinaliteit van de groep Phone 
van Customer is ingesteld op 1.3. Dat betekent dat er minstens één Phonegroep ver- 
eist is en dat er maximaal drie zijn toegestaan. Je hebt al in hoofdstuk 5 geleerd dat 
het entiteit-relatiemodel vereist dat er een ID-afhankelijke entiteit wordt gedefini- 
eerd voor het representeren van dergelijke meerwaardige attributen. Deze entiteit 
wordt later omgezet in een tabel in het relationele model. We negeren dat probleem 
hier. We tonen deze notatie alleen om je te laten zien hoe meerwaardige elementen 
worden gedocumenteerd in een XML Schema. 


Figuur 12-16 laat zien hoe het globale element PhoneType grafisch wordt weerge- 
geven door XML Spy. 
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<?xml ver 


sion="1.0" encoding="UTF-8"2> 


<xssschema xmins:xs="hteLpE//www.w3.org/2001/ ele 
eFormDefault="unqualifted"> 
<xs:complexType name="AddressType”> 
<xSs sequence? 
<x ement 
<xsrelement 
Sxsselement name > 
xs:element name e string” 
<xsselement name="Country” ty "xssstring” minOceur 
</xS: ce 


</xsscomplexlype> 


<xs:complexType name PhoneType”> 


SIS 


:sequence?> 
<xs:element name="AreaCode" tyf 
CS: 


element name="PhoneNum 


:sequence> 


</xs:complexlype> 
<xsrelement name="Customer"> 
Sxsrannotation> 


Sx 


</ 


s:documentation> 

This is the structured XML Schema for the VRG database 
with SALESPERSON added 

Ks:documentation> 


</xszannotation> 


CAS: 


CXS:S 


complexlype> 
quence> 
Cxszelement name 


“CustomerID” type="xs:int"/> 
LastName” type="xs:string 
lement name="FirstName” type="xs 


Cxsrelement name 

<3 

Sxszelement name="Address" type="Addr 
min0ecurs="0"/> 


ring”/> 


ype” 


<xs:element name="Phone” type="PhoneType” minOccurs="0"/> 


<xs:element name="EmailAddress” type="xs:string” 
minOecurs="0"/> 
<xsrelement name="Salesperson”> 
CasrcomplexType> 
<xS:sequence> 
<xs:element name="SalespersoniD" type="xs:int"/> 
<xszelement name="LäastName” type="xs:stringa”/> 
Cxsselement name="FirstNe type="xs:string"”/> 
<xszelement name="Address" type="AddressType” 
min0eeurs="0"/> 
<xsrelement name="Phone” type="PhoneType" 
maxÒccurs="3"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element? 


</xs:sequence> 
</xs:complexType> 
xs:element> 
</xs:schema> 


Figuur 1 


PhoneType 


2-15 XML Schema met globale elementen 


= PhoneNumber | 


Figuur 12-16 Grafische weergave van het globale element Phonetype 
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Figuur 12-17 illustreert hoe de verwijzing naar PhoneType wordt weergegeven bin- 
nen Customer en Salesperson. 


“CustomeriD 


LastName 


“FirstName 


hen al een 


AreaCode 


“ PhoneNumber 


=H 


SalespersoniD 


LastName 


FirstName 


nnn EN 


| TAN | 
| | 
pen | 


Figuur 12-17 Grafische weergave van het schema van Figuur 12-15 


12.4 XML-documenten maken op basis van databasegegevens 


SQL Server, Oracle en MySQL hebben voorzieningen voor het genereren van XM L- 
documenten op basis van databasegegevens. De XML-kenmerken van Oracle verei- 
sen het gebruik van Java. We nemen hier niet aan dat je een Java-programmeur bent 
en we bespreken deze kenmerken hier daarom niet verder. Mocht je een Java-pro- 
grammeur zijn, dan kun je meer te weten komen over de XML-voorzieningen van 
Oracle op www.oracle.com. 

De voorzieningen van SQL Server, Oracle en MySQL worden in snel tempo ver- 
der ontwikkeld. Versie 7.0 van SQL Server voegde de expressie FOR XML toe aan de 
SELECT-syntaxis van SQL. Deze expressie werd overgenomen in SQL Server 2000. 
De SQL Server-groep heeft de mogelijkheden van SQL Server in 2002 uitgebreid 
met SQLXML, een klassenbibliotheek die te downloaden is van msdn.microsoft. 
com. SQLXML, die door de SQL Server-groep is geproduceerd, verschilt van ADO. 
NET. De kenmerken en functies van SQLXML en ADO.NET zijn samengevoegd in 
SQL Server 2005 en dit is voortgezet in SQL Server 2008. 
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SELECT.….FOR XML 
Kijk eens naar het volgende SQL-statement: 


SEIEECTms 
FROM ARTIST 
FOR XML RAW; 


De expressie FOR XML RAW draagt SQL Server op de waarden van de kolommen 
als attributen in het resulterende XML-document te plaatsen. Figuur 12-18 toont een 
voorbeeld van de resultaten van dit statement. Elke kolom wordt, zoals verwacht, op- 
genomen als een attribuut van het element ARTIST. 


<row ArtistlD="1" LastName="Miro" FirstName="Joan" 


Nationality="Spanish" _DateOfBirth="1893" DateDeceased="1983" /> 
<row ArtistlD="2" LastName="Kandinsky" FirstName="Wassily" 


Nationality="Russian * DateOfBirth="1866" DateDeceased="1944" /> 
<row ArtistlD="3" LastName="Klee" FirstName="Paul" 


Nationality="German" DateOfBirth="1879" DateDeceased="1940" /> 
<row ArtistlD="4" LastName="Matisse" FirstName="Henri" 


Nationality="French" DateOfBirth="1869" DateDeceased="1954" /> 
<row ArtistlD="5" LastName="Chagall" FirstName="Marc" 


Nationality="French" DateOfBirth="1887" DateDeceased="1985" /> 
<row ArtistlD="11" LastName="Sargent" FirstName="John Singer” 


Nationality="United States" DateOfBirth="1856" DateDeceased="1925" /> 
<row ArtistlD="17" LastName="Tobey" FirstName="Mark" 


Nationality="United States" DateOfBirth="1890" DateDeceased="1976" /> 
<row ArtistlD="18" LastName="Horiuchi" FirstName="Paul" 


Nationality="United States" DateOfBirth="1906" DateDeceased="1999" /> 
<row ArtistlD="19" LastName="Graves" FirstName="Morris" 


Nationality="United States" DateOfBirth="1920" DateDeceased="2001" /> 
<row ArtistlD="20" LastName="Anderson" FirstName="Guy" 


Nationality="United States" /> 


Figuur 12-18 Resultaten van FOR XML RAW 


Je kunt SQL Server ook opdragen de waarden van de kolommen in elementen te zet- 


ten in plaats van in attributen. Het volgende statement produceert een document 
zoals dat in Figuur 12-19. 


SELECT 
FROM ARTIST 
FOR XML AUTO, ELEMENTS; 


Het is ook mogelijk SQL Server op te dragen sommige kolommen in elementen en 
andere kolommen in attributen te plaatsen, door FOR XML EXPLICIT te gebrui- 
ken. Een bepaald ontwerp kan bijvoorbeeld alle kolomwaarden behalve surrogate 
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key-waarden in elementen plaatsen en alle surrogate key-waarden in attributen. De 
rechtvaardiging voor dat ontwerp is dat surrogate key-waarden geen betekenis heb- 
ben voor gebruikers — ze lijken dus meer op metadata dan op gegevens. De manier 
waarop dat gedaan wordt, valt buiten het bereik van dit hoofdstuk. Zie FOR XML EX- 
PLICIT in de documentatie van SQL Server voor meer informatie. 


<?xml version="1.0" encoding="UTF-8"2> 


MyData xmlns:xasi="http://www.w3.0rg/2001/XMLSchema- instance” xsi:noNamespac 
eSchemalocation="C:\inetpub\wwwroot \DBP\VRG\DBP-ell-Figure-12-11-D.xsd”Ò 
SARTIST> 
SArtistID>1</ArtistID> 
<Last! > Ma ro </LastName> 


< rstN > Joan </FirstNamed 
<Nationality>Spanish </Nationality> 
<Date0fBirth>189 DateOf Birthò 
<DateDeceased>1983</DateDeceased> 


S/ARTIST> 


SART IST > 
KArtistID>2</Artist [D> 
astName>Kandinsky </LastName> 
FirstName>Wassily </FirstName> 
<Nationality>Russian </Nationality> 


<Date0fBirthn>1866</DateOfBirtn> 
<DateDeceased>19d4</DateDeceased> 
</ARTIST> 
k ARTIST> 
<ArtistID>3</ArtistID> 
<LastName>Klee </LastName> 
<FirstName>Paul </FirstName> 
<Nationality>German </Nationality> 
<DateOfBirth>187/9</Date0fBirtn> 
<DateDeceased>1940</DateDeceasedd 
</ARTISTÒ 
SART ISTÒ 

<ArtistID>4</ArtistID> 


<LastName>Matisse </LastName> 
<FarstName>Henri </FirstName> 
<Nationality>French </Nationality> 


<DateOfBirth>1869</DateOfBirth> 
<DateDeceased>1954</DateDeceased> 
</ARTIST> 


<ARTIST> 
SArtistID>5</ArtistID> 
<LastName>Chagall </LastNamed 
<FirstName>Marc </FirstName> 
<Nationality>French </Nationality> 


<DateOfBirth>1887</Date0OfBirth> 
<DateDeceased>1985</DateDeceased? 


</ARTIST> 

SART ISTD 

<ArtistID>11</ArtistIiD> 
<LastName>Sargent </LastName> 
<FirstName>dohn Singer </FirstName> 
<Nationality>United States </Nationality> 


<Date0fBirth>1856</DateOfBirth> 
<DateDeceased>1925</DateDeceased> 
S/ARTIST> 


Figuur 12-19 Resultaat van FOR XML AUTO, ELEMENTS 
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SARTISTD 
<Artist[ID>17</ArtistID> 


<LastName>Tobey </LastName> 
<FirstName>lart </FirstName> 
<Nationality>United States </Nationality> 


<Date0fBirth>1890</Date0fBirth> 
<DateDeceased>19/6</DateDeceased? 


</ARTISTD 

SARTIST> 
SArtistID>18</ArtistID> 
<LastName>Horiuchi </LastName> 
<firstName>Paul </FirstName> 
<Nationality>United States </Nationality> 


<DateOfBirth>1906</Date0fBirth> 
<DateDeceased>1999C/Datedeceased> 
S/ARTIST> 
SARTIST> 
<ArtistID>19</ArtistID> 


<LastName>Graves </LastName?> 
<FirstName>Morris </FirstName> 
<Nationality>United States </Nationality> 


<DateOfBirth>1920</Date0fBirtn> 
<DateDeceased>2001</DateDeceased> 

S/ARTIST> 

SART IST> 
<ArtistID>20</ArtistID> 
<LastName>Anderson </LastName> 
<FirstName>Guy </FirstName> 
<Nationality>United States </Nationality> 

S/ARTIST> 

</MyData> 


Figuur 12-19 (vervolg) 


12.4.1 Meer tabellen selecteren met FOR XML 
FOR XML SELECT-statements zijn niet beperkt tot een SELECT op afzonderlijke 


tabellen — ze kunnen ook op joins worden toegepast. Het XML-document in Figuur 
12-20 is bijvoorbeeld gemaakt met behulp van de volgende join: 


SELECT CUSTOMER. LastName AS CustomerLastName, 
CUSTOMER. FirstName AS CustomerFirstName, 
ARTIST.LastName AS ArtistName 


FROM CUSTOMER, 
CUSTOMER ARTIST _INT, 
ARTIST 
WHERE CUSTOMER. CustomerID = CUSTOMER _ARTIST_INT.CustomerID 


AND CUSTOMER ARTIST _INT.ArtistID = ARTIST.ArtistID 
ORDER BY _CUSTOMER.LastName, ARTIST.LastNAme 
FOR XML AUTO, ELEMENTS; 
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Or nat 


version="1.0" encodin 


<MyData xmlns.xsi="http:/ 
S 


g="UTF-8"2D 
3.0rg/2001/XMLSchema- instance” xsi:noNamespace 
chemaLocation="C:\inetpub\www igure-12-13-A.xsd”"> 
<CUSTOMERD 
CustomerLastName>Bench </CustomertastName> 
C tomerFirstNa 
ST> 
<ArtistName>Chagal | </ArtistName> 
</ARTIST> 
SARTIST> 


ne>Michael </CustomerFirstName> 


<ArtistName>Matisse </ArtistName> 
</ART IS 
/CUSTOMER> 
<CUSTOMER> 
CustomerlastName>Bench </CustomerLastName> 
CustomerfFirstName>Melinda </CustomerFirstName> 
SART IST 
<ArtistName argent </ArtistName> 
</ART IST 
CUSTOMER 
CUSTOMERD 
CustomerLastName>Frederickson </CustomerlastName> 
CustomerFarstName>Mary Beth </CustomerFirstName> 
ART IST 
<ArtistName>Chagall </ArtistName> 
IS 
ST> 
tistName>Kandinsky </ArtistName> 
FS > 
SART IST> 
<ArtistName>Matisse </ArtistName> 
</ARTIS 
<ARTIST> 
<ArtistName>Miro </ArtistName> 
</ARTIST> 


</CUSTOMERD 


/ Hy Data> 
Figuur 12-20 Gedeelte van resultaten met FOR XML AUTO, ELEMENTS van een join 


SQL Server gebruikt de volgorde van de tabellen in de FROM:-clausule voor het be- 
palen van de hiërarchische plaatsing van de elementen in het gegenereerde XML- 
document. Het element op het bovenste niveau is hier CUSTOMER en het volgende 
element is ARTIST. De tabel CUSTOMER _ARTIST_INT komt niet in het gegene- 
reerde document voor, want er worden geen kolommen van deze tabel gebruikt in 
de SELECT. 

Je kunt SQL Server opdragen een XML Schema-statement toe te voegen aan het be- 
gin van het XML-document dat geschreven zal worden door de expressie FOR XML 
AUTO, XMLDATA. We doen dat hier echter niet, omdat het geproduceerde schema 
onderwerpen bevat die we niet in dit hoofdstuk behandelen. 

Je kunt ook een XML Schema van een XML-document produceren door dat door 
XML Spy te laten doen, waarbij het document als voorbeeld wordt gebruikt. Het 
schema in Figuur 12-21 is op die manier gemaakt. Merk op dat het element MyData 
een onbegrensd aantal CUSTOMER-elementen kan hebben en dat elke CUSTOMER 
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<?xml version="1.0" encoding="UTF-8"?> 
<xs1schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified” attributeformDefault="unqualified"> 
<xsrelement name="MyData"> 
<xs:annotationz 
<xs:documentation> 
This XML Schema is for the VRG Customer Artist Interest 
data generated by an SQL XML FOR AUTO, ELEMENTS query 
</xs:documentat ion? 
</xsrannotation> 
<xs:complexlype> 
<xs: sequence? 
<xsrelement name="CUSTOMER" maxOccurs="unbdounded" 
<xs:complexTyped 
<xs: sequence? 
<xs:element name="CustomerlastName"/ 
<xs element name="CustomerFirstName”/> 
<xsrzelement name="ARTIST" min0Occurs="0" 
maxOeccurs="unbounded” 
<xSs:complexType> 
<xs: sequence 
<xs:element name="ArtistName"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:sequence> 
</xs:complexlype> 
</xs:element?> 
</xs:schema> 


Figuur 12-21 XML Schema bij het document van Figuur 12-20 


een onbegrensd aantal ARTIST-elementen kan hebben — één voor elke kunstenaar in 
wie de klant geïnteresseerd is. 


Figuur 12-22 laat een grafische weergave zien van hetzelfde schema. De notatie 1.2 
in deze figuur betekent dat er minstens één CUSTOMER vereist is en dat een onbe- 
perkt aantal is toegestaan. 


= CustomerLastName 
= CustomerfirstName 


(| cusromer El 


NE 


raa 


= ArtistName 


Figuur 12-22 Grafische weergave bij Figuur 12-21 
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12.5 Een XML Schema voor alle aankopen door klanten 


Stel nu dat we een document willen maken dat alle gegevens bevat over aankopen 
door klanten. We moeten daartoe CUSTOMER aan TRANS aan WORK aan ARTIST 


joinen en de juiste gegevens selecteren. De volgende SQL produceert de vereiste 
gegevens: 


SELECT CUSTOMER. CustomerID, 
CUSTOMER. LastName AS CustomerLastName, 
CUSTOMER. FirstName AS CustomerFirstName, 
TRANS.TransactionID, SalesPrice, 
WORK.WorkID, Title, Copy, 
ARTIST.ArtistI0, ARTIST.LastName AS ArtistName 
FROM CUSTOMER, TRANS, [WORK], ARTIST 
WHERE CUSTOMER. CustomerID = TRANS.CustomerID 
AND _ TRANS.WorkID = WORK.WorkID 
AND WORK.ArtistID = ARTIST.ArtistID 
ORDER BY CUSTOMER.LastName, ARTIST.LastName 
FOR XML AUTO, ELEMENTS; 


In Figuur 12-23 zie je een gedeelte van de uitvoer van dit statement in SQL Server 
Management Studio. 


[E racronait SOL Sereen Pamagrmarst stie leid 


dre ha) ed 
x LRT LD ARE. 
TEN wa rsmamer wermiesram HAGmried ENA ot 


The SQL FOR XML 
AUTO, ELEMENTS 
query results 


EE etenereenn 


Figuur 12-23 Resultaat van FOR XML AUTO, ELEMENTS in SQL Server Management Studio 
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Een XML Schema voor dit SQL-statement zie je in Figuur 12-24. 
<?xml version="1.0" encoding="UTF-8"2> 
<xs:schema ámlns:xs="http://www.w3.0rg/2001/% 
elementFormDefault="qualified” attributeformDe 
<xsselement name="MyData”> 
CxSrannotationz 
<xs:documentation?> 
This 4ML Schema for the VRG Customer Purchase 
data generated by am SQL XML FOR AUTO, ELEMENTS query 
</xs:documentation> 
</xsrannotation> 
<xs1complexType> 
<xS:sequence> 
<xs:element name="CUSTOMER" maxOccurs="unbounded"> 
<xs:complexType> 
{xS:sequence> 
<xs:element name="CustomerlD” type="xstint"/ 
<xs:element name="CustomerlastName”/> 
<xs:element name="CustomerfirstName"/> 
<xsselement name="TRANS" minOccurs="0" 
maxOececurs="unbounded”"> 
<xs:complexType> 
<xs:sequence> 


<xs:element name="TransactionlD” type="xstint"/> 


<xs1element name= 
<xs:element name= 
<xs:complexlype> 
<xS:sequence> 


SalesPrice”/> 
WORK "> 


<xs:element name="WorkID" type="Xxs:tint"/> 


<xs:element name="Title"/> 
<xs:element name="Copy"/> 
<xsrelement name="ARTIST"> 
<xs:complexlype? 
{XS : sequence? 
<xs:element name="ArtistID" 
type="xs:int"/> 
Sxs:element name="ArtistName"/> 
/xs:sequence> 
</xs:complexlype> 
</xs:element> 
<Ixs:sequence> 
</xs:complexType> 
</xs:element> 
</xS:sequence> 
</xs:complexType> 
</xs:element> 
<IxS:sequenced 
</xs:complexType> 
</xs:element> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:schemad 


Figuur 12-24 XML Schema bij het SQL-statement voor de aankopen van klanten 
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12.5.1 Een schema met twee meerwaardige paden 

Stel nu dat je een XML-document wilt opstellen met alle klantengegevens van View 
Ridge. Je kunt een dergelijke view niet maken met een enkel SQL-statement, want 
deze view heeft twee meerwaardige paden. Je hebt een SQL-statement nodig dat alle 
aankoopgegevens van klanten ophaalt en een tweede SQL-statement dat alle interes- 
ses van klanten in kunstenaars ophaalt. 

XML Schema heeft deze beperking echter niet. Een XML-document mag zoveel 
meerwaardige paden hebben als de applicatie vereist. We moeten in dit geval alleen 
de schema's uit Figuur 12-21 en Figuur 12-24 met elkaar combineren. We kunnen 
dan meteen ook surrogaatsleutels toevoegen voor elk van de onderliggende tabellen. 


Je ziet het resultaat van het combineren van deze resultaten (via knippen en plakken 


in XML Spy!) in Figuur 12-25. 


„0rq/2001/XMLSchema” 


buteformDefault="unqualified"> 


L hema 4 for VRG Customer data 
with two multivalue paths 
‘documentation 
s:annotation> 
s:complexType 


“CUSTOMER” maxOccurs="unbounded”"> 


name="CustomerlD” type="xs:int"/> 
s:element name="LastName"/> 
zelement name="FirstName"/> 
<xsrelement name="TRANS" minOccurs="0" 
maxOeccurs="unbounded"> 
<xs:complexType> 
<xs: sequence» 
<xsrelement name="TransactionlD” type="xs:int"/> 
<xs:element name="SalesPrice”/D 
<xsrelement name="WORK"D 
<xs:complexType> 
Cxs: sequence? 
{xs:element name="WorkID" type="xs:int"/> 
<xs:element name="Title"/> 
<xs:element name="Copy"/> 
<xs:element name="ARTIST"> 
<xs:complexfype> 
<xs:sequence> 
<xs:element name="Artist 1D" 
type="Xxs: int"/> 
<xs:element name="tastName”/> 
<xs:relement name="FirstName"/> 


Figuur 12-25 View Ridge Customer View met twee meerwaardige paden 
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</xs:sequênce> 
</xs:complexType> 
</xsrelement?> 
</xs:sequenc 
</xs:complexType? 


e> 


</xs:element? 
<Ixs:sequence> 
</xs:complexlype> 
</xszelement? 
<xsrelement name="ArtistInterests"” min0Occurs="0" 
maxOccurs="unbounded” 
<xSscomplexlype> 
<xS: sequence? 
<xszelement name="ArtistID" type="xs:tint"/> 


name= 


*_minOccurs="0"/> 


min0Occurs 
</xs:sequence> 
</xs:complexType> 
</xs:element> 
</xs:sequenced 
</xs:complexType> 
</xs:element> 
</xS: sequence) 
</xs:complexlype?> 
</xs:element?> 
</xs:schema> 


Figuur 12-25 (Vervolg) 


12.6 Waarom is XML belangrijk? 


Je zou ondertussen redelijk bekend moeten zijn met de aard van XML en de XML- 
standaarden. Je weet dat XML een duidelijke scheiding maakt tussen de structuur, de 
inhoud en de materialisatie. De structuur wordt gedefinieerd via een DTD, of via een 
XML Schema-document. De inhoud wordt uitgedrukt als een XML-document en de 
materialisaties van een document worden uitgedrukt in een XSL-document. Je be- 
grijpt ook dat SQL-statements bruikbaar zijn voor het maken van XM L-documenten, 
maar alleen als die documenten maximaal één meerwaardig pad omvatten. Komen 
er meer van dergelijke paden voor in het document, dan moeten er meer SQL-state- 
ments worden uitgevoerd om het document op de een of andere manier in te vullen. 

Je vraagt je misschien af: ‘Dat zijn interessante ideeën, maar wat maakt deze nu 
eigenlijk zo belangrijk” Het antwoord is dat XML-processing een gestandaardiseer- 
de mogelijkheid biedt voor het beschrijven, valideren en materialiseren van een wil- 
lekeurige databaseview. 

Neem bijvoorbeeld de galerie View Ridge. Stel dat deze galerie al haar klantenge- 
gevens met een andere galerie wil delen — misschien vanwege een gezamenlijk ver- 
koopprogramma. Als beide galerieën het eens worden over een XML Schema zoals 
dat in Figuur 12-25, kunnen ze hun klantgegevensdocumenten voorbereiden aan 
de hand van dat schema. Ze kunnen een geautomatiseerd proces uitvoeren dat een 
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document controleert aan de hand van zijn schema, voordat ze het versturen. Op die 
manier worden alleen correcte gegevens overgedragen. Dat proces werkt natuurlijk 
beide kanten uit. View Ridge kan niet alleen zeker stellen dat het alleen geldige docu- 
menten verstuurt, maar ook garanderen dat het alleen geldige documenten ontvangt 
door de ontvangen documenten te valideren. 

En het beste komt nog: de tools voor het valideren van de documenten zijn pu- 
bliekelijk beschikbaar en gratis. De galerieën hoeven geen programmacode te schrij- 
ven voor het valideren. 

Elke galerie kan bovendien een eigen verzameling XSL-documenten ontwikke- 
len, waarmee ze de klantengegevensdocumenten op elke gewenste manier kunnen 
materialiseren. View Ridge kan een XSL-document ontwikkelen dat de gegevens op 
de computer van een klant weergeeft, een ander document dat dit doet op de com- 
puters van de verkopers en weer een ander document dat de gegevens op mobiele 
apparaten weergeeft, als de kopers van kunstwerken onderweg zijn, enzovoort. Deze 
XSL-documenten maken het mogelijk klantengegevens weer te geven, ongeacht of 
ze nu van de ene of van de andere galerie afkomstig zijn. 

Breid dat idee nu eens uit van twee kleine bedrijven naar een hele industrie. Stel 
bijvoorbeeld dat de makelaarswereld het eens wordt over een XML Schema-docu- 
ment voor lijsten met beschikbare huizen. Elk makelaarsbedrijf kan dan gegevens 
in de indeling van het schema produceren en lijsten uitwisselen met elk ander ma- 
kelaarsbedrijf. Elk bedrijf kan het schema gebruiken om zeker te stellen dat het al- 
leen geldige documenten verstuurt en dat het alleen geldige documenten ontvangt. 
Bovendien kan elke makelaar een eigen verzameling XS L-documenten ontwikkelen 
om lijsten met huizen op elke gewenste manier te materialiseren. Zijn de XSL-docu- 
menten eenmaal voorbereid, dan kan elke lijst van elke deelnemende makelaar wor- 
den weergegeven volgens de eigen materialisaties van het bedrijf. Figuur 12-26 laat 
een aantal XM L-standaarden zien, waar diverse industrieën aan werken. 


Kijk voor een ander voorbeeld eens naar de toenemende trend van e-commerce tus- 
sen bedrijven. Stel dat een grote winkelketen besluit orders aan zijn leveranciers te 
sturen in een bepaalde, gestandaardiseerde indeling en in antwoord op die orders 
verzendingsbevestigingen verwacht in een andere specifieke, gestandaardiseerde in- 
deling. Ze kunnen daartoe een XML Schema ontwikkelen voor orderdocumenten en 
een ander schema voor verzendingsbevestigingen. Ze kunnen deze XML Schema's 
dan op een website beschikbaar maken voor hun leveranciers. Alle leveranciers kun- 
nen dan bepalen hoe ze orders van de winkelketen zullen ontvangen en hoe ze ver- 
zendingsbevestigingen moeten terugsturen. 

De schema's kunnen door de winkelketen en al zijn leveranciers worden gebruikt 
om te garanderen dat ze alleen geldige XML-documenten verzenden en ontvangen. 
De winkelketen kan verder XSL-documenten ontwikkelen die de orderdocumenten 
en verzendingsbevestigingen transformeren in de specifieke indelingen die zijn ei- 


gen afdelingen Boekhouding, Transactieverwerking, Marketing en Algemeen ma- 
nagement nodig hebben. 
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Bedrijfstak Voorbeelden van standaarden 
Boekhouding American Institute of Certified Public Accountants (AICPA): Extensible 
Financial Reporting Markup Language (XFRML) [omslagpagina OASIS] 
Open Applications Group, Inc (OAG) 
Architectuur en Architecture, Engineering, and Construction XML Working 
bouw Group (aecXML Working Group) 
ConSource.com: Construction Manufacturing and Distribution Extensible 
Markup Language (cmdXML) 
Automobielindustrie Automotive Industry Action Group (AIAG) 
Global Automedia 
MSR: Standards for information exchange in the engineering 
process (MEDOC) 
The Society of Automotive Engineers (SAE): XML for the Automotive 
Industry — SAE J2008 [omslagpagina OASIS] 
Open Applications Group, Inc (OAG) 
Bankwezen Banking Industry Technology Secretariat (BITS): [omslagpagina OASIS) 
Financial Services Technology Consortium (FSTC): Bank Internet Payment 
System (BIPS) [omslagpagina OASIS] 
Open Applications Group, Inc (OAG) 
Elektronische Data Interchange Standards Association (DISA): [omslagpagina OASIS] 
gegevensuitwisseling |+ EEMA EDI/EC Work Group [omslagpagina OASIS) 
European Committee for Standardization/Information Society 
Standardization System (CEN/ISSS — het Europese pilotproject 
XML/EDI [omslagpagina OASIS] 
XMLEDI Group [omslagpagina OASIS) 
Human DataMain: Human Resources Markup Language (hrm) 
resources HR-XML Consortium [omslagpagina OASIS): JobPosting, CandidateProfile, 
Resume 
Open Applications Group (OAG): Open Applications Group Interface 
Specification (OASIS) [omslagpagina OASIS] 
Tapestry.Net: JOB markup language (JOB) 
Open Applications Group, Inc (OAG) 
Verzekeringswezen ACORD: Property and Casualty [omslagpagina OASIS), 
Life (XMLife) [omslagpagina OASIS] 
Lexica: iLingo 


Figuur 12-26 Voorbeelden van XML-bedrijfsstandaarden 


Deze XSL-documenten werken voor orders en verzendbevestigingen van alle 
leveranciers. 

Alle validaties en materialisaties worden in deze gevallen door geautomatiseerde 
processen uitgevoerd, zodra de XML Schema-documenten eenmaal zijn voorbereid 
en de XSL-documenten zijn geschreven. Een orderdocument hoeft nooit door een 
menselijke hand te worden aangeraakt nadat het bij de winkelketen is gemaakt, tot- 
dat de bestelde artikelen door de leverancier worden verzameld. 

De enige uitdaging die nog overblijft, is dus het invullen van de XML-documen- 
ten met databasegegevens, overeenkomstig het relevante XML Schema. Schema's 
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met maar één meerwaardig pad kunnen kun je invullen met SQL, maar dat legt te 
veel beperkingen op en nieuwere technologieën als ADO.NET maken het makkelij- 
ker databasegegevens in XML-documenten te transformeren en omgekeerd. 


12.7 Overige XML-standaarden 


Zoals je weet is XML ontwikkeld als een reeks standaarden. We hebben tot dusver 
XML, XSL, XSLT en XML Schema genoemd. Er zijn een aantal XML-standaarden 
waarover je zult horen. Figuur 12-27 laat er een paar zien die je misschien zult tegen- 
komen. Je kunt deze standaarden, de documentatie ervan en wat lesmateriaal ervoor 
vinden op de websites www.w3.org en www.xml.org. 

Naast de vier standaarden die we al bespraken, is er nog XPath, een standaard 
voor het adresseren van elementen in documenten. Expressies zoals <xsl:value-of 
select=“CustomerName/LastName” in Figuur 12-4 gebruiken de standaard XPath 
voor het zoeken van een specifiek element in het document. XPath omvat concepten 
van een andere standaard, XPointer, die is ontwikkeld om documenten op een ge- 
avanceerde manier naar elementen in andere documenten te laten verwijzen. 

SAX en DOM zijn verschillende methoden voor het parsen van XM L-documen- 
ten. Het proces van het parsen bestaat uit het lezen van een document, het onderver- 
delen van de documenten in componenten en het op een bepaalde manier reageren 
op die componenten — door ze bijvoorbeeld in een database op te slaan. XML-parsers 
valideren ook documenten aan de hand van de DTD's of XML Schema's. 

Een programma dat aan een XML-document werkt — bijvoorbeeld een XSLT-pro- 
cessor — en dat de SAX API wil gebruiken, roept de volgens SAX werkende parser 
aan en geeft daar de naam van het te parsen document aan door. De SAX-parser 
verwerkt het document en roept callback-objecten in de XSLT-processor aan als er 


Voorbeelden van standaarden 

+ OpenMLS: Real Estate Listing Management System (OpenMLS) 
[omslagpagina OASIS] 

* Real Estate Transaction Standard working group (RETS): Real Estate 

Transaction Standard (RETS) [omslagpagina OASIS] 

* IBM: [omslagpagina OASIS] 

* Flashline.com: Software Component Documentation DTD 

* Flashline.com: 

* INRIA: Koala Bean Markup Language (KBML) [omslagpagina OASIS] 

+ Marimba and Microsoft: Open Software Description Format (OSD) 
[omslagpagina OASIS] 

* Object Management Group (OMG): [omslagpagina OASIS] 

* Internet Engineering Task Force (IETF): Simple Workflow Access 
Protocol (SWAP) [omslagpagina OASIS] 

* Workflow Management Coalition (MMC): Wf-XML [omslagpagina OASIS] 


Bedrijfstak 
Makelaardij 


Software 


Figuur 12-27 Belangrijke XML-standaarden 
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bepaalde structuren worden gevonden. Een SAX-parser roept de XSLT-processor bij- 
voorbeeld aan als er een nieuw element wordt gevonden. De naam van het element, 
de inhoud ervan en andere relevante dingen worden in de aanroep doorgegeven. 

De DOM API werkt op basis van een ander paradigma. Een parser die volgens 
DOM werkt, verwerkt het hele XML-document en verwerkt een boomrepresentatie 
daarvan. Elk element in het document is een node in de boom. De XSLT-proces- 
sor kan daarna de DOM-parser aanroepen om bepaalde elementen te verkrijgen via 
XPath of een soortgelijk adresseringsschema. DOM vereist dat het hele document 
in één keer wordt verwerkt. Dat kan voor heel grote documenten betekenen dat er 
onredelijk veel opslagruimte nodig is. SAX is in dat geval een betere keuze. Moet de 
hele documentinhoud echter tegelijk beschikbaar zijn voor gebruik, dan is DOM de 
enige keuze. 

XQuery is een opkomende standaard voor het uitdrukken van algemene query’s 
in XML-documenten. Je kunt je XQuery voorstellen als SQL voor XM L-documenten. 
Deze standaard zal heel belangrijk worden voor de database/XML-wereld, als deze 
beschikbaar wordt. 

De laatste standaard, XML Namespaces, is uitermate belangrijk, omdat deze 
wordt gebruikt voor het combineren van verschillende vocabulaires in hetzelfde 
XML Schema. XM LNamespaces is te gebruiken voor het definiëren en ondersteu- 
nen van domeinen en voor het ondubbelzinnig maken van termen. Dat laatste is no- 
dig als een document synoniemen bevat. Stel bijvoorbeeld dat de term Instrument op 
twee verschillende manieren wordt gebruikt. Een van deze termen kan bijvoorbeeld 
verwijzen naar muziekinstrumenten en de subelementen (Fabrikant, Model, Materi- 
aal} hebben (zoals {Horner, Basklarinet, Hout}), terwijl de tweede term naar elektro- 
nische instrumenten verwijst en de subelementen (Fabrikant, Model, Voltage} heeft 
(zoals (RadioShack, Ohmmeter, 12 Volt}). De auteur van het XML Schema voor een 
dergelijk document kan twee verschillende namespaces definiëren, die elk een van 
deze definities bevatten. Het label van de namespace kan dan voor de complexType- 
definitie voor elk van deze definities van Instrument worden geplaatst, zoals we dat 
in onze schemadocumenten deden toen we het label xs gebruikten. Dat is niet alles 
wat er te weten valt over XMLNamespaces en je zult er ongetwijfeld meer over leren 
terwijl je met XML werkt. Zie www.w3.org voor meer informatie. 


Samenvatting 


Databaseverwerking en documentverwerking hebben elkaar nodig. Databaseverwer- 
king heeft documentverwerking nodig voor het representeren en materialiseren van 
databaseviews. Documentverwerking heeft databaseverwerking nodig voor de opslag 
van gegevens. 

XML is een verzameling standaarden die in samenwerking is ontwikkeld door 
de databaseverwerkende en de documentverwerkende gemeenschappen. XML le- 
vert een gestandaardiseerde, maar toch aan te passen manier voor het beschrijven 
van de inhoud van documenten. XML-documenten kunnen automatisch worden 
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gegenereerd op basis van databasegegevens en databasegegevens kunnen automa- 
tisch uit XML-documenten worden geëxtraheerd. 

XML kan weliswaar worden gebruikt voor het materialiseren van webpagina's, 
maar dat is een van de minst belangrijke doeleinden. Een veel belangrijker doeleinde 
is het beschrijven, representeren en materialiseren van databaseviews. XML bevindt 
zich in het front van de databaseverwerking. 

XML levert een duidelijke scheiding tussen de structuur, de inhoud en de materi- 
alisatie van een document. XML-tags zijn niet dubbelzinnig. 

Er worden twee manieren gebruikt voor het beschrijven van de inhoud van XML- 
documenten: Document Type Declarations (DTD's) en XML Schema's. Een XML- 
document dat zich aan zijn DTD houdt, wordt type-valid genoemd. Een document 
kan goedgevormd maar niet type-valid zijn — omdat het de structuur van zijn DTD 
overtreedt, of omdat het geen DTD heeft. 

XML-documenten worden getransformeerd als een XSLT-processor een XSL- 
document toepast op het XML-document. Een veelvoorkomende transformatie is het 
omzetten van het XML-document in HTM L-indeling. Andere transformaties zullen 
in de toekomst belangrijker worden. Er kunnen bijvoorbeeld XSL-documenten wor- 
den geschreven die hetzelfde orderdocument in verschillende indelingen transfor- 
meren die nodig zijn voor verschillende afdelingen, zoals Verkoop, Boekhouding en 
Productie. XSLT-processing is contextgevoelig — er wordt een actie ondernomen op 
basis van de specifieke context als er een item wordt gevonden. De meeste browsers 
hebben tegenwoordig een ingebouwde XSLI-processor. 

XML Schema is een standaard voor het beschrijven van de inhoud van een XML- 
document. XML Schema kan worden gebruikt voor het definiëren van eigen voca- 
bulaires. Documenten die zich aan een XML Schema houden, worden schemageldig 
genoemd. XML Schema-documenten zijn in tegenstelling tot DTD’s zelf ook XML- 
documenten, die aan de hand van hun schema zijn te valideren. Dat schema wordt 
onderhouden door het W3C. 

Schema's bestaan uit elementen en attributen. Er zijn twee soorten elementen: 
eenvoudige en complexe. Eenvoudige elementen hebben één datawaarde. Complex- 
Type-elementen kunnen meer geneste elementen bevatten. ComplexTypen kunnen 
ook attributen hebben. De elementen in een complexType kunnen eenvoudig zijn, 
of het kunnen andere complexTypen zijn. ComplexTypen kunnen ook reeksen van 
elementen definiëren. Een goede vuistregel is dat elementen gegevens represente- 
ren en dat attributen metadata representeren, hoewel deze regel geen deel uitmaakt 
van welke XML-standaard dan ook. 

XML Schema's (en documenten) kunnen meer structuur hebben dan de ko- 
lommen van een tabel. Er kunnen groepen gedefinieerd worden, zoals Telefoon en 
Adres. Een schema waarvan alle elementen op hetzelfde niveau staan, wordt een 
plat schema genoemd. Gestructureerde schema's zijn schema's die gedefinieerde 
subgroepen bevatten, zoals Telefoon en Adres. Elementen kunnen globaal gedefini- 
eerd worden om dubbele definities te vermijden. Gedupliceerde definities zijn onge- 


wenst, want het gevaar bestaat dat dergelijke definities niet meer consequent zullen 
zijn als de ene definitie wel en de andere niet wordt gewijzigd. 
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Oracle, SQL Server en MySQL kunnen XML-documenten produceren op basis van 
databasegegevens. De Oracle-voorzieningen vereisen het gebruik van Java. SQL 
Server ondersteunt een extra expressie voor het SQL-statement SELECT, de ex- 
pressie FOR XML. FOR XML kan gebruikt worden voor het produceren van XML- 
documenten waarin alle gegevens worden uitgedrukt als attributen, of alternatief als 
documenten waarin alle gegevens worden uitgedrukt als elementen. FOR XML kan 
niet alleen XML-documenten schrijven, maar ook XML Schema-beschrijvingen. De 
ontwikkelaar kan sommige kolommen in elementen en andere in attributen plaat- 
sen met FOR XML EXPLICIT. 

Als er SELECT-statements met meer tabellen worden geïnterpreteerd, dan zal de 
FOR XML-processor de volgorde van de tabellen gebruiken voor het bepalen van de 
hiërarchische volgorde van de elementen in het document. FOR XML kan worden 
gebruikt voor het produceren van XML-documenten met één meerwaardig pad. Do- 
cumenten met meer meerwaardige paden moeten in de applicatie, of op een andere 
manier, samengevoegd worden. 

XML is belangrijk omdat XML tegemoetkomt aan het delen van XML-documen- 
ten (en dus ook van databasegegevens) tussen organisaties. Is er eenmaal een XML 
Schema gedefinieerd, dan kunnen organisaties zeker stellen dat ze alleen schemagel- 
dige documenten ontvangen en versturen. Bovendien kunnen er XSL-documenten 
worden geschreven, die het mogelijk maken elk schemageldig XML-document uit 
elke willekeurige bron in andere gestandaardiseerde indelingen te transformeren. 
Deze voordelen worden zelfs nog belangrijker als bedrijfsgroepen het eens worden 
over gestandaardiseerde XML Schema's. XML komt ook tegemoet aan verwerking 
tussen bedrijven. 

Het hoofdstuk besluit met een korte beschrijving van overige XML-standaarden: 
XPath, SAX, DOM, XQuery en XMLNamespaces. 


Belangrijke termen 


document type declaration (DTD) gestructureerd schema 
Extensible Markup Language (XML) stylesheet 
not-type-valid type-valid 


Simple Object Access Protocol (SOAP) XML Schema 
SQL SELECT … FOR XML-statement 


Oefeningen 


1. Waarom hebben databaseverwerking en documentverwerking elkaar nodig? 
Wat is de relatie tussen HTML en XML? 

3. _ In welk opzicht biedt XML een gestandaardiseerd, maar toch aan te passen ma- 
nier om documenten te beschrijven? 

4. Watis SOAP? 

5. _Watzijnde problemen bij het interpreteren van een tag zoals <h2> in HTML? 

6. Wat iseen DTD en wat is het doel ervan? 
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7. Wat is het verschil tussen een goedgevormd XML-document en een type-valid 
XML-document? 

8. Waarom is het niet helemaal juist om te zeggen dat XML de volgende versie van 
HTML is? 

g. Watis de relatie tussen XML, XSL en XSLT? 

io. Leg het gebruik van het patroon {item, actie} uit in het verwerken van een 
XSL-document. 

ir. Wat is het doel van een XML Schema? 

2. Waarin verschillen XML Schema's van DTD's? 

3. Wat is een schemageldig document? 

ig. Leg uit welke kip-ofei-kwestie er optreedt bij het valideren van XML 
Schema-documenten. 

15. Leg uit wat het verschil is tussen eenvoudige en complexe elementen. 

16. Leg uit wat het verschil is tussen elementen en attributen. 

17. Noem een goede vuistregel voor het gebruik van elementen en attributen voor 
het representeren van databasegegevens. 

18. Bedenk zelf een voorbeeld van een plat XML Schema. 

19. Bedenk zelf een voorbeeld van een gestructureerd XML Schema. 

20. Wat is het doel van globale elementen? 

21. Welke vereiste geldt voor het verwerken van XML-documenten met Oracle? 

22. Leg uit wat het verschil is tussen FOR XML RAW en FOR XML AUTO, 
ELEMENTS. 

23. Wanneer zou je FOR XML EXPLICIT gebruiken? 

24. Wat is het belang van de volgorde van de tabellen in een SQL-statement dat ge- 
bruikmaakt van FOR XML? 

25. Leg in eigen woorden uit waarom SQL niet samen met FOR XML te gebruiken 
is voor het opstellen van een XML-document met twee meerwaardige paden. 

26. Waarom is de beperking die in vraag 25 wordt genoemd belangrijk? 

27. Leg in eigen woorden uit waarom XML belangrijk is voor databaseverwerking. 

28. Waarom is XML Schema belangrijk voor het delen van documenten tussen 
organisaties? 

29. Wat is XPath? 

30. Waarin verschilt DOM van SAX? 

31. Watis XQuery? Waar wordt dit voor gebruikt? 

32. Wat zijn XML Namespaces? Waar worden deze voor gebruikt? 

Projectvragen 

33. Maak een DTD en een XML-document zoals dat in Figuur 12-1 voor het repre- 
senteren van een rij van de tabel ARTIST uit hoofdstuk 7. 

34. Gebruik Figuur 12-4 als voorbeeld en maak een XSL-document voor het mate- 


rialiseren van het document uit je antwoord op vraag 32. Gebruik een browser 
voor het materialiseren van je document. 
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35: 


36. 


37 


38. 


Maak een XML Schema-document voor een rij van TRANSACTION. Plaats 
Transaction[D als een attribuut. Groepeer aankoopgegevens in een complex- 
Type en groepeer verkoopgegevens in een tweede complexType. Gebruik Figuur 
12-12 als voorbeeld. 

Maak een XML Schema voor kunstenaars en de klanten die in hen geïnteres- 
seerd zijn. Gebruik Figuur 12-21 als voorbeeld. 

Maak een XML Schema voor kunstenaar-, werk-, transactie- en klantengege- 
vens. Gebruik Figuur 12-24 als voorbeeld en verwerk je antwoord op vraag 35 in 
het schema. 

Maak een XML Schema voor alle kunstenaargegevens. Gebruik Figuur 12-25 en 
je antwoord op vraag 35. 


Marcia’s Chemische Reiniging 


Beantwoord vraag A tot en met G voor Marcia’s Chemische Reiniging aan het eind 


van hoofdstuk 7, op pagina 292, als je dat niet al hebt gedaan. Gebruik SQL Server, 
Oracle of MySQL. 


À. 


B. 


Maak een XML-document met een DTD voor een rij van de tabel CUSTOMER. 
Gebruik Figuur 12-r als voorbeeld. 

Gebruik Figuur 12-4 als voorbeeld en maak een XSL-document voor het materi- 
aliseren van het document dat je in vraag A maakte. Geef je document weer in 
een browser. 

Maak een XML Schema-document voor een join van CUSTOMER- en IN- 
VOICE-gegevens. Neem aan dat het document één klant en nul tot veel orders 
voor die klant bevat. Gebruik Figuur 12-21 als voorbeeld. 

Gebruik FOR XML voor het schrijven van een SQL-statement dat het document 
zal produceren dat je in vraag C hebt gemaakt. 

Maak een XML Schema-document dat alle gegevens bevat voor een gegeven 
klant. Hoeveel meerwaardige paden heeft dit schema? 

Leg uit hoe Marcia’'s Chemische Reiniging er nut van kan hebben het XML 
Schema-document te gebruiken dat je in vraag E hebt gemaakt. 


Importbedrijf Morgan 


Beantwoord vraag A tot en met H voor Importbedrijf Morgan aan het eind van hoofd- 
stuk 7, op pagina 294, als je dat niet al hebt gedaan. Gebruik SQL Server, Oracle of 
MySQL. 


À. 


B. 
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Maak een XML-document met een DTD voor een rij van de tabel PURCHASE. 
Gebruik Figuur 12-1 als voorbeeld. 

Gebruik Figuur 12-4 als voorbeeld en maak een XSL-document voor het mate- 
rialiseren van het document dat je in vraag A hebt gemaakt. Geef je document 
weer in een browser. 
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Maak een XML Schema-document voor een join van STORE- en PURCHASE- 
gegevens. Neem aan dat het document één winkel en nul tot veel aankopen voor 
die winkel bevat. Gebruik Figuur 12-21 als voorbeeld. 

Gebruik FOR XML voor het schrijven van een SQL-statement dat het document 
zal produceren dat je in vraag C hebt gemaakt. 

Maak een XML Schema-document dat alle gegevens bevat voor een gegeven 
aankoop. Hoeveel meerwaardige paden heeft dit schema? 

Leg uit hoe Ilmportbedrijf Morgan er nut van kan hebben het XML Schema- 
document te gebruiken dat je in vraag E hebt gemaakt. 
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Hoofdstuk 13 
Databaseverwerking voor 
business intelligence-systemen 


Business intelligence-systemen (bedrijfsinformatiesystemen), kortweg Bl-systemen 
of ook wel decision support systems (DSS) genoemd, zijn informatiesystemen die ma- 
nagers en andere professionals helpen huidige en voorafgaande activiteiten te analy- 
seren en toekomstige gebeurtenissen te voorspellen. Ze ondersteunen, in tegenstelling 
tot systemen die transacties verwerken, geen bedrijfsactiviteiten zoals het registreren 
en verwerken van bestellingen. Bl-systemen worden gebruikt als ondersteuning van 
het management door informatie te leveren bij het beoordelen, analyseren, plannen, 
beheren en uiteindelijk bij het nemen van beslissingen. 
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13.1 De relatie tussen bedrijfs- en Bl-systemen 


In Figuur 13-1 zie je een overzicht van de relatie tussen bedrijfssystemen en business 
intelligence-systemen. Bedrijfssystemen zoals orderinvoer, inkoop, fabricage en in- 
ventaris ondersteunen voornamelijk bedrijfsactiviteiten. Ze gebruiken het DBMS 
voor het lezen van gegevens uit en het opslaan van gegevens in de bedrijfsdatabase. 


Bedrijfs- | 
DBMS CE WO 


Bedrijfs- 
applicaties 


(orderinvoer, 


Md — 
f0 / 


fabricage, 
Functionele inkoop, 
gebruikers inventaris 


enzovoort) 


Uittreksel 
uit bedrijfs- 
database 


Bedrijfsinformatieapplicaties 


Ne 


Í Ì / 
Gebruikers voor 
management en 

ondersteuning van 
management 


Aangekochte 
gegevens 


Figuur 13-1 Soorten datatypenRelatie tussen bedrijfssystemen en bedrijfsinformatiesystemen 


Bl-systemen verkrijgen op drie verschillende manieren gegevens. Ten eerste lezen 
en verwerken ze gegevens uit de bedrijfsdatabase. Merk op dat ze het bedrijfs-DB- 
MS gebruiken voor het verkrijgen van gegevens, maar dat ze geen bedrijfsgegevens 
invoegen, wijzigen of verwijderen. Ten tweede verwerken BlI-systemen uittreksels 
uit bedrijfsdatabases. Ze beheren de geëxtraheerde database in dat geval met be- 
hulp van een BI-DBMS. Dat kan hetzelfde DBMS zijn als het bedrijfs-DBMS, of 
een ander DBMS. Bl-systemen lezen ten slotte gegevens die zijn aangekocht van 
gegevensleveranciers. 


13.2 Applicaties voor rapportage en datamining 


BlI-systemen zijn in twee brede categorieën onder te verdelen: rapportage en data- 
mining. Rapportagesystemen sorteren, filteren en groeperen bedrijfsgegevens en 
voeren eenvoudige berekeningen uit op deze gegevens, zoals je in dit hoofdstuk zult 
zien. Dataminingapplicaties analyseren gegevens op ingewikkelde en subtiele ma- 
nieren door ingewikkelde statistische en wiskundige bewerkingen uit te voeren. 

De kenmerken van Bl-applicaties zijn samengevat in Figuur 13-2. 


13.2.1 Rapportageapplicaties 


Rapportagesystemen filteren, sorteren, groeperen en voeren eenvoudige berekenin- 
gen uit. Alle rapportageanalyse kan worden uitgevoerd met standaard-SQL, hoewel 
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* Rapportage 

= filteren, sorteren, groeperen en uitvoeren van 
eenvoudige berekeningen 

— samenvatten van de huidige toestand 

— vergelijken van de huidige met een voorgaande of een 
voorspelde toestand 

= classificeren van entiteiten (klanten, producten, 
werknemers enzovoort) 


— het afleveren van rapporten is van groot belang 
e Datamining 


— maakt vaak gebruik van geavanceerde statistische en 
wiskundige technieken 
— wordt gebruikt voor: 
e wat-als-analyses 
* voorspellingen 
* besluitvorming 
— de resultaten worden vaak opgenomen in een ander 
rapport of systeem 


Figuur 13-2 Kenmerken van Bl-applicaties 


er soms uitbreidingen op SQL worden gebruikt, zoals die welke worden gebruikt 
voor OnLine Analytical Processing (OLAP), om de taak van het produceren van rap- 
porten te vereenvoudigen. 

Rapportagesystemen vatten de huidige toestand van bedrijfsactiviteiten samen 
en vergelijken deze toestand met voorgaande of met voorspelde toekomstige acti- 
viteiten. De aflevering van rapporten is van groot belang. De rapporten moeten op 
tijd en in de juiste indeling aan de juiste gebruikers worden geleverd. De rapporten 
kunnen op papier worden geleverd, via een browser, via de telefoon, via een digitaal 
dashboard of op een willekeurige andere manier. 


13.2.2 Applicaties voor datamining 
Applicaties voor datamining maken gebruik van geavanceerde statistische en wis- 
kundige technieken voor het uitvoeren van wat-als-analyses, het maken van voor- 
spellingen en het helpen bij de besluitvorming. Dataminingtechnieken kunnen 
bijvoorbeeld worden gebruikt voor het analyseren van het gebruik van mobiele te- 
lefoons, om te voorspellen welke klanten vermoedelijk naar een concurrerend tele- 
foonbedrijf zullen overstappen. Of er kan datamining worden gebruikt om gegevens 
over voorgaande leningen te analyseren, om te bepalen welke klanten het meest (of 
het minst) waarschijnlijk in gebreke zullen blijven bij de afbetaling van een lening. 
Het afleveren van rapporten is minder belangrijk voor systemen voor datamining 
dan voor rapportagesystemen. De meeste applicaties voor datamining hebben om 
te beginnen maar een paar gebruikers — en die gebruikers hebben geavanceerde 
computervaardigheden. De resultaten van datamininganalyses worden bovendien 
gewoonlijk opgenomen in een ander rapport, een andere analyse of een ander infor- 
matiesysteem. De kenmerken van de klanten bij wie het gevaar bestaat dat ze naar 
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een ander bedrijf overstappen, worden in het geval van het gebruik van mobiele tele- 
foons aan de verkoopafdeling doorgegeven, zodat deze actie kan ondernemen. Of de 
parameters van een vergelijking voor het bepalen van de waarschijnlijkheid van het 
in gebreke blijven bij de afbetaling van leningen, kunnen in een applicatie voor het 
goedkeuren van leningen worden opgenomen. 


13.3 Datawarehouses en datamarts 


Zoals je in Figuur 13-1 ziet, lezen en verwerken sommige Bl-systemen bedrijfsgege- 
vens rechtstreeks vanuit de bedrijfsdatabase. Hoewel dat mogelijk is voor eenvoudige 
rapportagesystemen en kleine databases, is het rechtstreeks lezen van bedrijfsgege- 
vens niet haalbaar voor ingewikkelder applicaties of grotere databases. Deze grotere 
applicaties verwerken gewoonlijk een afzonderlijke database, die is gemaakt op basis 
van een uittreksel uit de bedrijfsdatabase. 

Er zijn diverse redenen waarom bedrijfsgegevens moeilijk te lezen zijn. Om te 
beginnen kan het opvragen van gegevens voor Bl-applicaties het DBMS aanzien- 
lijk belasten en de prestaties van bedrijfsapplicaties onacceptabel verminderen. 
Bedrijfsgegevens hebben bovendien problemen die hun nut voor Bl-applicaties 
beperken. Het maken en onderhouden van Bl-systemen vereist verder program- 
ma's, voorzieningen en expertise die normaliter niet beschikbaar zijn in de gewone 
bedrijfsomgeving. 

Veel organisaties hebben er vanwege deze problemen voor gekozen datawarehou- 
ses en datamarts te ontwikkelen voor het ondersteunen van Bl-applicaties. Laten we 
eerst eens een paar van de problemen bekijken bij het gebruik van bedrijfsgegevens 


voor Bl-verwerking, voordat we op de onderdelen van datawarehouses en datamarts 
ingaan. 


13.3.1 De onderdelen van een datawarehouse 

Veel organisaties hebben datawarehouses opgezet om de zojuist beschreven pro: 
blemen te overkomen. Datawarehouses zijn databasesystemen die gegevens, pro- 
gramma's en personeel omvatten die gespecialiseerd zijn in het voorbereiden van 
gegevens voor Bl-verwerking. Datawarehousedatabases verschillen van bedrijfsdata- 
bases, want de gegevens in een datawarehouse zijn vaak gedenormaliseerd. Datawa- 
rehouses kunnen variëren in hun omvang en bereik. 

Figuur 13-3 toont de onderdelen van een datawarehouse. Extractieprogramma's 
lezen gegevens uit bedrijfsdatabases, zuiveren deze en bereiden ze voor op Bl-ver- 
werking. Dergelijke programma’s heten wel ETL-systemen (Extract, Transform and 
Load). De geëxtraheerde gegevens worden opgeslagen in een datawarehousedata- 
base met behulp van een datawarehouse-DBMS. Dat kan een ander DBMS zijn 
dan het bedrijfs-DBMS van de organisatie. Een organisatie kan bijvoorbeeld Oracle 
gebruiken voor de bedrijfsverwerking, maar SQL Server voor het datawarehouse. 
Andere organisaties kunnen SQL Server gebruiken voor de bedrijfsverwerking en 
gegevensbeheertools van leveranciers van statistiekpakketten, zoals SAS of SPSS, 
voor het datawarehouse. 
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Figuur 13-3 De onderdelen van een datawarehouse 


13.3.2 Problemen met bedrijfsgegevens 

De meeste bedrijfsdatabases hebben problemen die hun nut beperken voor alle 
behalve de allereenvoudigste Bl-applicaties. Figuur 13-4 toont een lijst met de be- 
langrijkste probleemcategorieën. Om te beginnen moeten gegevens die van kritiek 
belang zijn voor succesvolle bedrijfswerkzaamheden volledig en nauwgezet zijn — 
gegevens die maar enigszins noodzakelijk zijn, hoeven dat niet te zijn. Sommige 
bedrijfssystemen verzamelen bijvoorbeeld demografische klantengegevens tijdens 
het proces van het bestellen. 


e dirty data 
ontbrekende waarden 
niet-consequente gegevens 
gegevens zijn niet geïntegreerd 
verkeerde indeling 


— te gedetailleerd 

— niet gedetailleerd genoeg 
e te veel gegevens 

— te veel attributen 

— te groot volume 


Figuur 13-4 Problemen van het gebruiken van transactiegegevens voor bedrijfsinformatie 


De kwaliteit van de demografische gegevens zal er echter onder lijden, omdat der- 
gelijke gegevens niet nodig zijn voor het verzamelen, verzenden of factureren van 
bestelde artikelen. 

Problematische gegevens noemen we dirty data. Voorbeelden zijn de waar- 
de G voor het geslacht van een klant en de waarde 213 voor de leeftijd van een 
klant. Andere voorbeelden zijn een waarde van 9999-999999 voor een telefoon- 
nummer, een onderdeelkleur zoals ‘gron’ en een e-mailadres zoals “WaaromIk@ 
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ErgensInHetUniversum.wie’. Deze waarden leveren allemaal problemen op voor de 
doeleinden van de rapportage en datamining. 

Er ontbreken vaak elementen in aangekochte gegevens. De meeste gegevensle- 
veranciers geven in feite op hoeveel procent van de waarden voor elk attribuut er 
ontbreekt in de gegevens die ze verkopen. Een organisatie koopt dergelijke gegevens 
omdat wat gegevens voor sommige doeleinden beter zijn dan helemaal geen gege- 
vens. Dat geldt vooral voor gegevensitems waarvan de waarden moeilijk te verkrijgen 
zijn, zoals het aantal volwassenen in een huishouden, het inkomen van een huis- 
houden, het soort woning en de opleiding van de hoofdkostwinner. Het is geen al te 
groot probleem voor rapportageapplicaties als er wat gegevens ontbreken. Maar voor 
dataminingapplicaties kunnen een paar ontbrekende of foutieve gegevens feitelijk 
erger zijn dan helemaal geen gegevens, omdat ze de analyse scheeftrekken. 

Het derde probleem in Figuur 13-4, inconsequente gegevens, komt vooral veel 
voor bij gegevens die in de loop van de tijd zijn verzameld. Als er bijvoorbeeld een 
netnummer wordt veranderd, dan kan het telefoonnummer van een gegeven klant 
na deze wijziging anders zijn dan het voor de wijziging was. Onderdeelcodes kun- 
nen ook veranderen, net als verkoopgebieden. Dergelijke gegevens zullen we op- 
nieuw moeten coderen, zodat ze consequent zijn over de tijdsperiode van de studie, 
voordat we ze kunnen gebruiken. 

Neem bijvoorbeeld een op het web gebaseerd bestelformuliersysteem dat door 
klanten over de hele wereld wordt gebruikt. Welke tijdzone moet de webserver nu 
gebruiken als deze de tijd van een bestelling registreert? De tijd van de systeemklok 
van de server is niet relevant voor een analyse van het gedrag van de klanten. Elke 
andere standaardtijd, zoals de Universal Time Co-ordinated (UTC) tijd is ook beteke- 
nisloos. De tijd van de webserver moet op de een of andere manier aan de tijdzone 
van de klant worden aangepast. 

Niet-geïntegreerde gegevens zijn nog een ander probleem. Stel bijvoorbeeld dat 
een organisatie een rapport wil zien over het bestel- en betalingsgedrag van klanten. 
De bestelgegevens zijn echter jammer genoeg opgeslagen in een door Siebel ont- 
wikkeld CRM-systeem, terwijl de betalingsgegevens zijn opgeslagen in een database 
voor financieel beheer van PeopleSoft. De gegevens moeten op de een of andere ma- 
nier worden geïntegreerd om de analyse te kunnen uitvoeren. 

Gegevens kunnen ook te gedetailleerd of juist te grof zijn. Stel dat we de plaatsing 
van afbeeldingen en besturingselementen in een bestelformulier-webpagina willen 
analyseren. Het klikgedrag van de klanten kan worden geregistreerd in zogenaamde 
click-stream data. Click-stream data omvatten echter alles wat de klant doet. Midden 
in de bestelstroom kunnen gegevens voorkomen over klikken op nieuws, e-mail, 
chatvensters en weerberichten. Al deze gegevens mogen weliswaar nuttig zijn voor 
een studie van het computergedrag van de consumenten, maar dit is te veel als we 
alleen willen weten hoe de klanten op een advertentie in het scherm reageren. De ge- 
gevensanalisten moeten vele miljoenen klikken weggooien voordat ze door kunnen 
gaan, omdat de gegevens te gedetailleerd zijn. 

De gegevens kunnen ook te grof zijn. Een bestand met de totaalbedragen van be- 
stellingen is niet bruikbaar voor een market basket-analyse, die artikelen identificeert 
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die vaak samen worden gekocht. Een market basket-analyse vereist gegevens op 
artikelniveau — we moeten weten welke artikelen samen met welke andere artikelen 
werden gekocht. Dat wil niet zeggen dat de gegevens met totaalbedragen van bestel- 
lingen nutteloos zijn. Deze kunnen voldoen voor andere analyses — ze voldoen alleen 
niet voor een market basket-analyse. 

Gegevens die te gedetailleerd zijn, kunnen grover worden gemaakt. Een analist 
en een computer kunnen dergelijke gegevens optellen en combineren. Het is echter 
onmogelijk te grove gegevens in hun samenstellende onderdelen te scheiden. 

Het laatste in Figuur 13-4 getoonde probleem betreft het gegevensvolume. We 
kunnen te veel rijen, te veel kolommen of te veel van beide hebben. De binnen de 
organisatie opgeslagen klantengegevens en de klantengegevens die worden aange- 
kocht, kunnen samen betekenen dat we met honderd of meer verschillende attribu- 
ten of kolommen rekening moeten houden. Maar hoe kiezen we daartussen? Hoe 
meer attributen er zijn, hoe makkelijker het wordt een model te bouwen dat bij de 
voorbeeldgegevens past, maar dat waardeloos is voor het voorspellen. Het aantal at- 
tributen moet om deze en andere redenen worden verminderd. Een van de belang- 
rijkste activiteiten in de datamining betreft dan ook het efficiënt en effectief kiezen 
van variabelen. 

Ten slotte kunnen we te veel instanties, of rijen met gegevens hebben. Stel dat 
we click-stream data van CNN.com willen analyseren. Er treden op deze site miljoe- 
nen en nog eens miljoenen klikken per maand op! Willen we deze gegevens op een 
zinvolle manier analyseren, dan moeten we het aantal instanties terugbrengen. Het 
nemen van statistische monsters is een goede oplossing voor dat probleem. Het ont- 
wikkelen van een betrouwbaar monster vereist echter gespecialiseerde expertise en 
speciale tools voor het informatiesysteem. 


13.3.3 Aangekochte gegevens van gegevensleveranciers 
Datawarehouses bevatten vaak gegevens die zijn aangeschaft bij bronnen buiten de 
organisatie. De kredietgegevens van klanten zijn daar een typisch voorbeeld van. 
Figuur 13-5 toont een deel van de consumentengegevens die je kunt kopen bij een le- 
verancier die AmeriLINK heet. Een verbazingwekkende — en vanuit het oogpunt van 
de privacy angstaanjagende — hoeveelheid gegevens is verkrijgbaar bij alleen deze 
ene leverancier. 

Metadata over de bron en de indeling van de gegevens, de aannames en de voor- 
waarden voor de gegevens worden bijgehouden in een datawarehouse metadata- 
database. Het DBMS van het datawarehouse extraheert en levert gegevens aan 
Bl-tools, zoals dataminingprogramma’s. 


13.3.4 Datawarehouses versus datamarts 

Je kunt je een datawarehouse voorstellen als een groothandel in een bevoorradings- 
keten. Het datawarehouse krijgt gegevens van de gegevensleveranciers (bedrijfssys- 
temen en aangekochte gegevens), zuivert en verwerkt deze en zoekt de gegevens als 
het ware op in de schappen van het datawarehouse. De mensen die in een dataware- 
house werken, hebben expertise in gegevensbeheer, het zuiveren van gegevens, het 
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e naam, adres, telefoonnummer 

e leeftijd, geslacht 

e ethniciteit, religie 

e inkomsten 

e opleiding 

e huwelijkse status, leeftijdscategorie 

e lengte, gewicht, haar- en oogkleur 

e naam van huwelijkspartner, 
geboortedatum enzovoort 

e namen en geboortedatums van kinderen 

e stemregistratie 

e huiseigendom 

e voertuigen 

e tijdschriftabonnementen 

e catalogusbestellingen 

e hobby's 

e standpunten 


Figuur 13-5 AmeriLINK verkoopt gegevens over meer dan 230 miljoen Amerikanen 


omzetten van gegevens en dergelijke. Ze hebben echter meestal geen expertise in 
een bepaalde bedrijfsfunctie. 

Een datamart bevat minder gegevens dan het datawarehouse en spreekt een spe- 
cifiek onderdeel of functioneel gebied van het bedrijf aan. Een datamart lijkt op een 
kleinhandel in een bevoorradingsketen. Gebruikers in de datamart verkrijgen gege- 
vens die betrekking hebben op een specifieke bedrijfsfunctie van het datawarehouse. 
Dergelijke gebruikers hebben niet de expertise in het gegevensbeheer dat de werkne- 
mers van het datawarehouse hebben, maar ze zijn goed ingelichte analisten op het 
gebied van een bepaalde bedrijfsfunctie. 

Figuur 13-6 licht deze relaties toe. Het datawarehouse neemt gegevens aan van de 
gegevensleveranciers en distribueert de gegevens aan drie datamarts. De eerste data- 
mart analyseert click-stream data voor het doel van het ontwerpen van webpagina's. 
De tweede analyseert opgeslagen verkoopgegevens en bepaalt welke producten vaak 
samen worden gekocht. Deze informatie wordt gebruikt om verkopers te trainen 
in het overreden van klanten om meer te kopen. De derde datamart analyseert be- 
stelgegevens van klanten met als doel de inspanning voor het ophalen van artikelen 
uit het warenhuis te verminderen. Een bedrijf zoals Amazon doet bijvoorbeeld veel 
moeite zijn warenhuizen te organiseren om de kosten voor het ophalen van artike- 
len te verminderen. 


Je zult je kunnen voorstellen dat het maken, bemannen en exploiteren van dataware- 
houses en datamarts duur is. Alleen grote organisaties met veel geld kunnen het zich 
veroorloven een systeem zoals dat in Figuur 13-6 te gebruiken. Kleinere organisaties 
werken met subsets van dit systeem — ze hebben bijvoorbeeld misschien alleen een 
eenvoudige datamart voor het analyseren van reclamegegevens. 
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Weblog- Lette L_, Kenmerken voor 
Metadata Dataware- gegevens Klikanalyse Ë ontwerpen van 
van data- house- webpagina's 
warehouse database Datamart voor verkoop via het web | 
Market basket- 


Winkel- 


Dataware- 
house-DBMS 


Gegevens- 
producenten 


voor 
winkelbeheer 


» analyse voor 
trainen van verkopers 


gegevens 


Datamart voor verkoop via winkels 


Gegevens 
over 
verloop van 
inventaris 


Inventarisindeling 
» voor optimale 
toegang tot artikelen 


Bl-tools voor 
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Figuur 13-6 Datawarehouses en datamarts 


13.4 Rapportagesystemen 


Een rapportagesysteem heeft tot doel betekenisvolle informatie samen te stellen op 
basis van sterk verschillende datasources en die informatie op tijd aan de juiste ge- 
bruikers te leveren. Rapportagesystemen verschillen, zoals we al eerder hebben op- 
gemerkt, van datamining omdat ze informatie creëren met behulp van eenvoudige 
bewerkingen (sorteren, filteren en groeperen) en het uitvoeren van eenvoudige be- 
rekeningen. We beginnen dit deel met een beschrijving van een typisch rapportage- 
probleem: RFM-analyse. 


13.4.1 RFM-analyse 

RFM-analyse is een manier voor het analyseren en ordenen van klanten overeen- 
komstig hun koopgedrag. Het is een eenvoudige techniek die rekening houdt met 
hoe recentelijk (R) een klant heeft besteld, hoe vaak (frequently — F) de klant bestelt 
en hoeveel geld (money — M) de klant per bestelling besteedt. RFM wordt samenge- 
vat in Figuur 13-7. 


e Eenvoudig, op rapporten gebaseerd classificatieschema 
voor klanten 


e Geef klanten een score op basis van wanneer, hoe vaak 


en voor hoeveel geld ze bestellen 
e Verdeel elk criterium normaliter in vijf groepen en 
geef een score van 1 tot 5 


Figuur 13-7 RFM-analyse 


Er wordt een RFM-score geproduceerd door de aankooprecords van klanten eerst te 
sorteren op de datum van hun meest recente bestelling (R). De klanten worden in 
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een gebruikelijke vorm van deze analyse in vijf groepen onderverdeeld en er wordt 
een score van 1 tot 5 toegekend aan de klanten in elke groep. De klanten in de 20% 
met de meest recente bestellingen krijgen dus een R-score van 1, de klanten in de 
20% met de daaropvolgende meest recente bestellingen krijgen een R-score van 2, 
enzovoort, tot aan de klanten in de laatste 20%, die een R-score van 5 krijgen. 

De klanten worden daarna gesorteerd op basis van hoe vaak ze bestellen. De klan- 
ten in de 20% met de meeste bestellingen krijgen een F-score van 1, de klanten in de 
volgende 20% krijgen een F-score van 2, enzovoort, tot aan de klanten die het minst 
vaak bestellen, die een F-score van 5 krijgen. 

Ten slotte worden de klanten nog eens gesorteerd op basis van de waarde van 
hun bestellingen. De klanten in de 20% die de duurste dingen hebben besteld, krij- 
gen een M-score van 1, de klanten in de volgende 20% krijgen een M-score van 2, 
enzovoort, tot aan de 20% klanten die het minst hebben besteed en die een M-score 
van 5 krijgen. 

Figuur 13-8 toont een voorbeeld van RFM-gegevens. De eerste klant, Ajax, heeft 
recentelijk besteld en bestelt vaak. De M-score van 3 geeft echter aan dat Ajax niet 
de duurste goederen bestelt. Het verkoopteam kan uit deze scores opmaken dat Ajax 


een goede klant is en dat ze hun best moeten doen te proberen Ajax duurdere goe- 
deren te verkopen. 


Figuur 13-8 Een voorbeeld van RFM-scores 


De tweede klant in Figuur 13-8 kan een probleem zijn. Bloominghams heeft al enige 
tijd niets besteld, maar bestelde in het verleden wel vaak en hun bestellingen waren 
van de hoogste waarde. Deze gegevens suggereren dat Bloominghams misschien op 
het punt staat naar een andere leverancier over te stappen. Iemand van het verkoop: 
team zou meteen contact met hen moeten opnemen. Niemand van het verkoopteam 
zou aan de andere kant met de derde klant, Caruthers, moeten praten. Deze klant 
heeft al enige tijd niets besteld, ze bestellen niet vaak en als ze al bestellen, kopen ze 
alleen goedkope dingen — en maar weinig daarvan. 

Caruthers kan rustig naar een concurrent gaan. De laatste klant, Davidson, zit 
daar precies tussenin. Davidson is een redelijke klant, maar niemand in de verkoop: 
afdeling zou er veel tijd aan moeten besteden. 
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13.4.2 Het RFM-rapport produceren 


Net als de meeste rapporten kan een RFM-rapport worden gemaakt met een reeks 
SQL-expressies. Deze paragraaf presenteert twee opgeslagen procedures voor SQL 
Server die RFM-scores leveren. Daarvoor gebruiken we de vijf tabellen uit Figuur 


13-9. 


2REATE TABLE CUSTOMER SALES 


CustomerID Int 
TransactionID Int 
TransactionDate DateTime ' 
OrderAmt Money ‚ 
CONSTRAINT Customer Sales PK 

PRIMARY KEY(TransactionID 


REATE TABLE CUSTOMER RFM 
CustomerID Int 


R smal lInt Ò r 
F SmallInt ' 
M SmallInt 
CONSTRAINT Customer REM PK 


PRIMARY KEY (Customer ID 


CREATE TABLE CUSTOMER R 


CustomerID Int ! 7 
MostRecentOrderDate DateTime N 5 

R SmalliInt Î 1, 
CONSTRAINT Customer _R PK 


PRIMARY KEY (CustomerID 


CREATE TABLE CUSTOMER F 


CustomerID Int NOT NULL, 
OrderCount Int NI ; 

R SmalliInt NULL, 
CONSTRAINT Customer_F_PK 


PRIMARY KEY (CustomerID) 


CREATE TABLE CUSTOMER M 


CustomerID Int ", 
AverageOrderAmount Money ’ 

R SmallInt 7) 
CONSTRAINT Customer M PK 


PRIMARY KEY (CustomerID! 


Figuur 13-9 SQL Server-tabellen voor RFM-analyse 
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De tabel CUSTOMER SALES bevat de gegevens die worden gebruikt voor de 
RFM-berekeningen. CUSTOMER_RFM bevat CustomerlD en de uiteindelijke R-, 
F- en M-scores. De resterende drie tabellen, CUSTOMER_R, CUSTOMER_F en 
CUSTOMER_M worden gebruikt voor het opslaan van tussenresultaten. Merk op 
dat alle CustomerlD-kolommen NOT NULL zijn. 

De opgeslagen procedure in Figuur 13-10 berekent de RFM-scores. De procedure 
begint met het verwijderen van de resultaten van een eventuele voorgaande analyse 
uit de tabellen CUSTOMER_R, CUSTOMER _F en CUSTOMER _M. Daarna wor- 
den drie procedures aangeroepen voor het berekenen van de R-, F- en M-scores. Ten 
slotte worden deze scores opgeslagen in de tabel CUSTOMER-RFM. Dat is de enige 
tabel die nodig is voor rapportagedoeleinden. 


Je ziet de procedure Calculate_R in Figuur 13-11. Deze procedure plaatst de datum 
van de meest recente bestelling van elke klant om te beginnen in de kolom Most- 
RecentOrderDate. De procedure gebruikt daarna de Top … Percent-optie van het SQL 
SELECT-statement om de waarden van R_Score in te stellen. Het eerste UPDATE- 
statement stelt de waarde van R_Score in op r voor de eerste 20% van de klanten (na- 
dat deze in aflopende volgorde zijn gesorteerd op MostRecentOrderDate). R_Score 
wordt daarna ingesteld op 2 voor de eerste 25% van de klanten die een nullwaarde 
hebben voor R_Score in de aflopende volgorde van MostRecentOrderDate. De proce- 
dure gaat door met het instellen van de R-waarden voor alle klanten. De procedures 


Calculate_F en Calculate_M zijn soortgelijk en we laten deze als een oefening aan de 
lezer over in vraag 52. 


De tabel CUSTOMER_RFM wordt gebruikt voor rapportagedoeleinden. Figuur 13-12 
toont een SELECT op CUSTOMER _RFM die is voorbereid met behulp van een data- 
base met meer dan vijfduizend klanten en meer dan een miljoen transacties. Het 
voorbereiden van de tabel CUSTOMER_RFM nam minder dan 30 seconden in be- 
slag op een middelmatig krachtige pc. 

De resultaten in Figuur 13-12 zijn interessant, maar zullen uiteindelijk geen waar- 
de hebben voor de organisatie, tenzij deze informatie aan de juiste gebruikers wordt 
geleverd. De twaalfde rij in deze figuur laat bijvoorbeeld zien dat er 202 klanten zijn 
met een RFM-score van {5 1 1}. Deze klanten bestellen vaak en ze bestellen dure 
dingen, maar ze hebben niet recentelijk besteld. Het bedrijf loopt misschien het 
gevaar deze klanten te verliezen. Dit rapport en de namen van de klanten die deze 
score hebben, moeten op de een of andere manier aan het juiste verkooppersoneel 
ter beschikking worden gesteld (zie ook vraag 23). We bekijken de onderdelen van 
een rapportagesysteem om te begrijpen met welke moderne middelen dat gedaan 
kan worden. 


eer TETE 7 VENIR TEN 
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'E PROCEDURE RFM Analysis 


M CUSTOMER R; 


FROM | 
FROM CUSTOMER _F; | 
FROM CUSTOMER M; 


Calculate _R; 
Calculate F; 
> Calculate M: 


R_ Score AS R Count 
CUSTOMER _R 
BY R Score; 


ST F_ Score, C AS F_ Count | 
CUSTOMER _F 
BY F Score; 


M Score, \f AS M Count 
î CUSTOMER _M 
GROUP BY M Score; 


INSERT INTO CUSTOMER RFM (CustomerID 
SELECT CustomerID 
FROM CUSTOMER SALES, ; 


UPDATE CUSTOMER RFM 
SET R 
SELECT R Score 
FROM CUSTOMER _R 
WHERE CUSTOMER RFM.CustomerID CUSTOMER _R.CustomerID, ; 


UPDATE CUSTOMER RFM 
SEL F 
(SELECT F Score 
FROM CUSTOMER F 
WHERE CUSTOMER RFM.CustomerID CUSTOMER F.CustomerID: ; 


UPDATE CUSTOMER RFM \ 
SET M 
(SELECT M Score 
FROM CUSTOMER M 


WHERE CUSTOMER RFM.CustomerID CUSTOMER _M.CustomerID ; 


Figuur 13-10 Opgeslagen procedure voor de RFM-analyse 
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CREATE PROCEDURE Calculate _R 


[AEK Compute R Score RRKIKKKRK KR KR te dek Kok ke dek ke kk ie Kk KEK HH / 


INSERT INTO CUSTOMER _R CustomerID, MostRecentOrderDate 
(SELECT CustomerID, Max (TransactionDate 
FROM CUSTOMER SALES 
GROUP BY CustomerID 


UPDATE CUSTOMER _R 

SET R_ Score 1 

WHERE CustomerID 
(Select Top 20 Percent CustomerID 
FROM CUSTOMER _R 
ORDER BY MostRecentOrderDate DESC); 


UPDATE CUSTOMER _R 

SET R_ Score 2 

WHERE CustomerID 
(Select Top 25 PERCENT CustomerID 
FROM CUSTOMER _R 
WHERE R_ Score 


ORDER BY MostRecentOrderDate DESC 


UPDATE CUSTOMER _R 
SET R_ Score 3 
WHERE CustomerID 
(Select Top 33 PERCENT CustomerID 
FROM CUSTOMER _R 
WHERE R Score 
ORDER BY MostRecentOrderDate DESC) ; 


UPDATE CUSTOMER _R 
SET R Score 4 
WHERE CustomerID iN 
(Select Top 50 PERCENT CustomerID 
FROM CUSTOMER _R 
WHERE R_ Score TS NULL 
ORDER BY MostRecentOrderDate DESC) ; 


UPDATE CUSTOMER _R 
SET R Score — 5 
WHERE CustomerID :N 
(Select CustomerID 
FROM CUSTOMER R 
WHERE R Score 15 NULL); 


Figuur 13-11 De procedure Calculate_R 
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[pe SQL-query voor 
de RFM-resultaten 
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Figuur 13-12 Een voorbeeld van RFM-resultaten 


13.4.3 De onderdelen van een rapportagesysteem 

Figuur 13-13 toont de belangrijkste onderdelen van een rapportagesysteem. Gege- 
vens uit sterk verschillende datasources worden gelezen en verwerkt. Rapportage- 
systemen kunnen zoals je ziet gegevens verkrijgen uit bedrijfsdatabases, vanuit 
datawarehouses en vanuit datamarts. Sommige gegevens worden binnen de orga- 
nisatie gegenereerd, andere worden verkregen uit publieke bronnen en weer andere 
worden aangekocht bij gegevensleveranciers. 


} 


} 


Webportaal 


Metadata van 
rapportage- 
systeem 


Bedrijfs- 
database 


DE 


Dataware- Rapportage- 
Î 
en Ze 
database en 


e schrijven 
e beheren 
e leveren 


En/of 


waarschuwing | 
4 


ne ee 


\ 
Gebruikers 


Datamart- 
database 


_webservice — 


Figuur 13-13 De onderdelen van een rapportagesysteem 


505 


DEELS | STANDAARDEN VOOR OATABASETOEGANG 


Een rapportagesysteem houdt een database bij met rapportage-metadata. De meta- 
data beschrijven rapporten, gebruikers, groepen, rollen, gebeurtenissen en andere 
entiteiten die bij de rapportageactiviteit betrokken zijn. Het rapportagesysteem ge- 
bruikt de metadata voor het voorbereiden en het op tijd afleveren van de juiste rap- 
porten in de juiste indeling aan de juiste gebruikers. 

Zoals je in Figuur 13-13 ziet, kunnen rapporten in allerlei verschillende indelin- 
gen worden voorbereid. Figuur 13-14 toont een lijst met kenmerken van rapporten. 


Type Medium 


Statisch Papier 


Dynamisch Webportaal 


Digitaal dashboard 


OnLine Analytical 
Processing (OLAP) 


E-mail/waarschuwing 


XML-webservice en 
_ | epplicatiespecitiek 


Figuur 13-14 Kenmerken van rapporten 


13.4.4 Soorten rapporten 

Sommige rapporten zijn statisch. Ze worden eenmaal voorbereid op basis van de 
onderliggende gegevens en veranderen nooit. Een rapport met de verkoopcijfers van 
het afgelopen jaar is bijvoorbeeld een statisch rapport. Andere rapporten zijn dyna- 
misch — het rapportagesysteem leest de nieuwste, meest actuele gegevens op het mo: 
ment dat de rapporten gemaakt worden en genereert de rapporten met behulp van 
deze ‘verse’ gegevens. Rapporten met de verkoopcijfers van vandaag of de huidige 
aandelenkoersen zijn dynamische rapporten. 

Queryrapporten worden voorbereid in reactie op door gebruikers ingevoerde 
gegevens. Google is een voorbeeld van een queryrapport. Je voert de sleutelwoor- 
den in waarnaar je wilt zoeken en het rapportagesysteem van Google doorzoekt zijn 
database en genereert een antwoord dat specifiek is voor jouw query. Binnen een 
organisatie zou een queryrapport kunnen worden gegenereerd om de huidige in- 
ventarisniveaus te tonen. De gebruiker voert artikelnummers in en het rapportage- 
systeem reageert door de inventarisniveaus weer te geven voor de diverse winkels en 
warenhuizen. 

Een OLAP- of OnLine Analytical Processing-rapport is weer een ander soort rap- 
port. OLAP-rapporten maken het de gebruiker mogelijk de groeperingstructuren 
van het rapport dynamisch te veranderen. Je ziet later in dit hoofdstuk een voorbeeld 
van het gebruik van een OLAP-rapport. 
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13.4.5 Media voor rapporten 

Rapporten worden tegenwoordig op veel verschillende manieren afgeleverd. Som- 
mige rapporten worden op papier afgedrukt, andere worden gemaakt in indelingen 
zoals PDF, die we kunnen afdrukken of elektronisch kunnen bekijken. Weer andere 
worden via webportalen afgeleverd. Een organisatie kan verkooprapporten op het 
webportaal van de verkoopafdeling plaatsen en een rapport over geholpen klanten op 
het webportaal van de klantenserviceafdeling. 

Een digitaal dashboard is een elektronisch display dat is aangepast voor een spe- 
cifieke gebruiker. Bedrijven zoals Yahoo! en MSN bieden digitale dashboardservices. 
Gebruikers van deze services kunnen definiëren welke inhoud ze willen zien — bij- 
voorbeeld een plaatselijke weersvoorspelling, een lijst met aandelenkoersen of een 
lijst met nieuwsbronnen — en de leverancier stelt de aangepaste weergave samen 
voor elke gebruiker. Dergelijke pagina's worden My Yahoo! of My MSN genoemd, of 
iets dergelijks. Andere dashboards zijn specifiek voor een organisatie. Het leidingge- 
vende personeel bij een fabricageorganisatie kan bijvoorbeeld een dashboard hebben 
dat actuele productie- en verkoopactiviteiten toont. 

Rapporten kunnen ook worden afgeleverd via waarschuwingen of alerts. De 
gebruikers kunnen opgeven dat ze via e-mail of via sms op hun mobiele telefoon 
gewaarschuwd willen worden als er nieuws is of als er bepaalde gebeurtenissen op- 
treden. Er zijn natuurlijk ook mobiele telefoons die webpagina's kunnen weergeven 
en die ook digitale dashboards kunnen gebruiken. 

Rapporten kunnen ten slotte ook worden afgeleverd aan andere informatie- 
systemen. De moderne manier daarvoor is het publiceren van rapporten als een 
XML-webservice. Deze manier van rapporteren is vooral nuttig voor informatie- 
systemen die door meer organisaties worden gebruikt, zoals voor het beheren van 
bevoorradingsketens. 


13.4.6 De rapportagemodus 

Het laatste kenmerk van rapporten in Figuur 13-14 is de rapportagemodus. Een 
pushrapport wordt op basis van een vooraf bepaald rooster naar de gebruikers 
verstuurd. De gebruikers ontvangen het rapport, zonder dat ze daar zelf iets voor 
hoeven doen. Een pullrapport is een rapport dat door de gebruikers moet worden 
aangevraagd. Een gebruiker verkrijgt een pullrapport door naar een webportaal of 
een digitaal dashboard te gaan en op een knop of een hyperlink te klikken die het 
rapportagesysteem opdraagt het rapport te produceren en af te leveren. 


13.5 De functies van een rapportagesysteem 


Zoals je in Figuur 13-13 ziet, zijn rapportagesystemen bedoeld voor het uitvoeren van 
drie functies: het schrijven, het beheren en het afleveren van rapporten. 
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13.5.1 Rapporten schrijven 
Het schrijven van een rapport omvat het maken van een verbinding met de juiste 
datasources, het ontwerpen van de structuur van het rapport, en de opmaak van het 
rapport. Figuur 13-15 en Figuur 13-16 tonen het gebruik SQL Server Business Intelli- 
gence Development Studio om een rapport te produceren met de resultaten van een 
RFM-analyse in SQL Server. SQL Server Business Intelligence Development Studio 
is een onderdeel van SQL Server 2008. 

In Figuur 13-15 heeft de ontwikkelaar een database opgegeven die de tabel CUS- 
TOMER_RFM bevat en hij heeft net het in Figuur 13-12 getoonde SQL-statement in- 
gevoerd. Je ziet dit SQL-statement iets onder het midden in deze afbeelding. 


Ë 


Query Degner 


Dante Gre | GOED ' > Es 


De tabel 
CUSTOMER_RFM 


De RFM-query 
als QBE 


De RFM-query 
als SQL-statement 


Cekumn an Table Outp. Sor Iype Sort Order 
‚ R Ì CUSTOME Pi 

' CUSTOM 

D 


De RFM-query 
als SQL-statement 


| CusTont / 
Hamte 4 Descending 1 
| 


SELECT RFN COUNT) AS HumberOfCustemen 
RGM CUSTOMER EM 

GROUP BV REM 

EDER Ef hiamberOtCamtemer: MSC 


1 cs » vi 


Figuur 13-15 Een gegevensbron opzetten voor een rapport 


In Figuur 13-16 maakt de auteur het rapport op door de koppen aan te geven en de 
opmaak voor de gegevens te kiezen. De auteur zou voor een ingewikkelder rapport 
ook het sorteren en groeperen van de gegevens aangeven, evenals kop- en voetregels 
voor de pagina's. De ontwikkelaar gebruikt de eigenschappenlijst links in de weer- 
gave in Figuur 13-16 voor het instellen van de waarden van de eigenschappen die de 
items hebben. 


Je ziet het uiteindelijke rapport, zoals dat in een browservenster wordt weergegeven, 
in Figuur 13-17. Zoek op www.microsoft.com naar ‘reporting services’ als je meer wilt 
weten over deze applicatie. 
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Figuur 13-16 Opmaken van het rapport met SQL Server BĲ Development Studio 
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Figuur 13-17 Het RFM-rapport in een webbrowser 


13.5.2 Rapporten beheren 
Het beheren van rapporten heeft als doel te definiëren wie welke rapporten op wel- 
ke manier ontvangt. De meeste rapportenbeheersystemen maken het de beheerder 
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mogelijk gebruikersaccounts en gebruikersgroepen te definiëren en gebruikers aan 
bepaalde groepen toe te kennen. Alle verkopers kunnen bijvoorbeeld aan de verkoop- 
groep worden toegekend, alle leidinggevende medewerkers aan de management- 
groep, enzovoort. Deze gegevens worden allemaal opgeslagen in de in Figuur 13-13 
getoonde metadata van het rapportagesysteem. 

Met hetzelfde systeem waarmee je rapporten maakt, kun je rapporten aan groe- 
pen en gebruikers toekennen. Het toekennen van rapporten aan groepen bespaart 
de beheerder werk. Als een rapport wordt gemaakt, gewijzigd of verwijderd, hoeft de 
beheerder de wijziging alleen aan de betreffende groep door te geven. Alle gebrui- 
kers in de groep zullen de wijzigingen meekrijgen. De metadata over de toekenning 
van rapporten omvatten niet alleen de gebruiker of de groep en de toegekende rap- 
porten, maar geven ook aan in welke indeling en via welk medium het rapport bij de 
gebruiker moet worden afgeleverd. 

Figuur 13-18 laat bijvoorbeeld het in XML gematerialiseerde RFM-rapport zien. 
Het XML-bestand kan dan in een willekeurig programma worden ingevoerd dat 
XML consumeert en het is dan op de in hoofdstuk 12 beschreven manier via XSL te 
manipuleren. 

De metadata voor het rapportenbeheer geven aan, zoals we al opmerkten, in wel- 
ke indeling het rapport naar welke gebruikers moet worden verstuurd. Ze geven ook 
aan welk medium er moet worden gebruikt en of het rapport automatisch moet wor- 

den afgeleverd (push), of dat het moet worden opgehaald (pull). De beheerder geeft 


voor pushrapporten op of ze volgens een vaststaand rooster of als een waarschuwing 
moeten worden gegenereerd. 


13.5.3 Rapporten afleveren 


De functie van een rapportagesysteem voor het afleveren van rapporten zal de rap- 
porten automatisch afleveren (push), of toestaan dat ze worden opgehaald (pull), 
op basis van de metadata van het rapportenbeheer. De rapporten kunnen via een 
e-mailserver worden afgeleverd, via een webportaal, via XML-webservices of op an- 
dere manieren die specifiek zijn voor het programma. Het afleversysteem voor de 
rapporten gebruikt het besturingssysteem en andere onderdelen voor de program- 
mabeveiliging om te garanderen dat alleen geautoriseerde gebruikers geautoriseerde 
rapporten ontvangen. Het afleversysteem zorgt er ook voor dat pushrapporten op de 
juiste tijden worden geproduceerd. 

Het afleversysteem voor rapporten fungeert voor queryrapporten als een bemid- 
delaar tussen de gebruiker en de rapportengenerator. Het afleversysteem neemt 
querygegevens aan van de gebruiker (zoals de artikelnummers in een inventaris- 
query), geeft de querygegevens door aan de rapportengenerator, ontvangt het resul- 
terende rapport en levert dat rapport af aan de gebruiker. 
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Figuur 13-18 Het RFM-rapport in XML 


13.6 OLAP 


OLAP, een tweede soort van rapportagesysteem, is een meer algemene soort toepas- 
sing dan RFM. OLAP levert de mogelijkheid eenvoudige rekenkundige bewerkingen 
uit te voeren op groepen gegevens. Voorbeelden hiervan zijn optellen, tellen en het 
berekenen van het gemiddelde. Opmerkelijk kenmerk van OLAP-rapporten is dat 
ze dynamisch zijn. De indeling van het rapport kan worden gewijzigd door de lezer. 
Vandaar de term online in OnLine Analytical Processing. 

Een OLAP-rapport heeft maateenheden en dimensies. Een maateenheid (of mea- 
sure) is het gegevensitem waarin mensen geïnteresseerd zijn — dit is het item dat 
op de een of andere manier in het OLAP-rapport moet worden verwerkt (optellen, 
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gemiddelde berekenen, enzovoort). De totale verkoop, de gemiddelde verkoop of de 
gemiddelde kosten zijn voorbeelden van maateenheden. Een dimensie is een ken- 
merk van een maateenheid. De aankoopdatum, de woonplaats van de klant en het 
verkoopgebied zijn allemaal voorbeelden van dimensies. 

Figuur 13-19 toont een gebruikelijk OLAP-rapport. De maateenheid is hier de net- 
towinkelverkoop (Store Sales Net) en de dimensies zijn de productsoort en het type 
winkel. Dit rapport laat zien hoe de nettowinkelverkoop varieert per productsoort en 
per type winkel. Winkels van het type Supermarket hebben bijvoorbeeld netto voor 
$ 36.189 aan niet-consumeerbare (non-food) goederen verkocht. 


vJDeluxe Supermarket Gourmet Supermarket Mid-Size Grocer) Small Grocery Supermarket [Grand zE 


$2,39283 $1.,409.50 368569 _ $15,75171| $29,58% 

€ 870.276 11 $2002518 _ $1039219  $5,10372 $128 960 67| $245,76487 
7_|Non-Consumable $18.834 24 $5 05479 $281373 _$153490 _ $35,18940| $64,487 05 
$97 27940 $27 48380 $14615 42 8533051 __#191 501 77| 5339 610 60) 


Figuur 13-19 Een OLAP-rapport van de nettoverkoop van productsoort/winkeltype 


De weergave van een maateenheid met de daarmee verbonden dimensies, zoals die 
in Figuur 13-19, wordt vaak een OLAP-kubus genoemd, soms ook gewoon een ku- 
bus. Deze term wordt gebruikt omdat sommige producten deze gegevens met drie 
assen weergeven, als een meetkundige kubus. Een OLAP-kubus is hetzelfde als een 
OLAP-rapport. 

Het OLAP-rapport in Figuur 13-19 is weergegeven in een Excel-tabel. De gegevens 
zijn afkomstig uit een educatieve voorbeelddatabase met de naam Food Mart, die bij 
SQL Server wordt geleverd. OLAP-kubussen kunnen ook op veel andere manieren 
worden weergegeven dan met Excel. Sommige leveranciers van tools bieden geavan- 
ceerdere grafische weergaven. OLAP-rapporten kunnen verder op dezelfde manier 
worden afgeleverd als welk van de andere voor rapportenbeheersystemen beschre- 
ven rapporten dan ook. 

Het kenmerk dat OLAP-rapporten onderscheidt is, zoals we al eerder opmerk- 
ten, dat de gebruiker de indeling van het rapport kan veranderen. Figuur 13-20 toont 
een dergelijke wijziging. De gebruiker heeft hier een extra dimensie, Store Location, 
aan de horizontale weergave toegevoegd. De verkoop per productsoort is nu onder- 
verdeeld naar winkellocatie. De voorbeeldgegevens omvatten winkels in de staten 
Californië, Oregon en Washington. 

Het is met een OLAP-rapport mogelijk in de gegevens omlaag te boren (drill 
down). Het omlaag boren betekent dat de gegevens verder, in meer detail, worden on- 
derverdeeld. De gebruiker heeft in Figuur 13-21 bijvoorbeeld omlaag geboord in de 
winkels die zich in Californië bevinden. Het OLAP-rapport toont nu verkoopgege- 
vens voor de vier steden in Californië die winkels hebben. 
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Figuur 13-21 Een OLAP-rapport met verschillende locaties in Californië 


Merk ook op dat er nog een verschil is tussen Figuur 13-20 en Figuur 13-21. De ge- 
bruiker heeft niet alleen omlaag geboord, maar ook de volgorde van de dimensies 
veranderd. Figuur 13-20 toont de productsoort en dan de winkelplaats binnen de 
productsoort. Figuur 13-21 toont de winkelplaats en dan de productsoort binnen de 
winkelplaats. 

Deze weergaven zijn beide geldig en nuttig, afhankelijk van het gezichtspunt van 
de gebruiker. Een productmanager ziet misschien het liefst eerst de productsoort 
en dan de gegevens over de winkelplaats. Een verkoopmanager ziet misschien lie- 
ver eerst de winkelplaats en dan de productgegevens. OLAP-rapporten bieden beide 
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gezichtspunten en de gebruiker kan daartussen schakelen terwijl hij het rapport 
bekijkt. 

Al deze flexibiliteit heeft jammer genoeg wel een prijs. Als de database groot is, 
is een aanzienlijke rekenkracht nodig om de berekeningen, groeperingen en sorte- 
ringen uit te voeren die een dergelijke dynamische weergave vereist. Hoewel dit een 
standaard is, hebben commerciële DBMS-producten geen kenmerken en functies 
die nodig zijn voor het maken van OLAP-rapporten. Ze zijn niet voor dergelijk werk 
ontworpen. Ze zijn ontworpen om snel te kunnen reageren op transactieverwer- 
kingsapplicaties, zoals orderinvoer of fabricageplanning. 

Er zijn dan ook speciale producten ontwikkeld voor het uitvoeren van OLAP-ana- 
lyses. Deze producten worden OLAP-servers genoemd. Zoals je in Figuur 13-22 ziet, 
leest een OLAP-server gegevens uit een bedrijfsdatabase, voert deze voorlopige bere- 
keningen uit en slaat deze de resultaten van deze berekeningen op in een OLAP-da- 
tabase. De OLAP-server en het DBMS draaien om prestatie- en beveiligingsredenen 
meestal op afzonderlijke computers. De OLAP-server bevindt zich gewoonlijk in het 
datawarehouse of in een datamart. 
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Figuur 13-22 De rol van de OLAP-server en de OLAP-database 


13.7 Datamining 


Datamining is de toepassing van wiskundige en statistische technieken voor het zoe- 
ken van patronen en relaties, die kunnen worden gebruikt om te classificeren en te 
voorspellen. Zoals je in Figuur 13-23 ziet, vertegenwoordigt datamining het samen: 
komen van diverse fenomenen. Technieken voor datamining zijn ontstaan vanuit de 
statistische en wiskundige disciplines en vanuit de gemeenschappen rondom kunst- 
matige intelligentie en lerende machines. De terminologie van datamining is in feite 
een vreemde combinatie van termen afkomstig uit deze verschillende disciplines. 
Dataminingtechnieken maken gebruik van ontwikkelingen voor het verwerken 
van enorme databases, die in de afgelopen jaren zijn ontstaan. Al die gegevens zou- 
den natuurlijk niet zijn gegenereerd als computers niet zo snel en goedkoop waren 
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geworden — en de nieuwe technieken zouden onmogelijk te berekenen zijn zonder 
dergelijke computers. 


Statistiek/ 
wiskunde 


Kunstmatige intelligentie 
Lerende machines 


Enorme 


Dataminin 
databases Ee 


Technieken 
voor 
gegevensbeheer 


Goedkope 
computerverwerking 
en opslag 


Goed opgeleide 
professionals 
(marketing, financiën 
en andere gebieden 


Figuur 13-23 Samenkomen van diverse disciplines in datamining 


De meeste dataminingtechnieken zijn geavanceerd en moeilijk te gebruiken. Der- 
gelijke technieken zijn echter waardevol voor organisaties. Sommige zakelijke pro- 
fessionals — vooral op het gebied van financiën en marketing — hebben expertise 
ontwikkeld in het gebruik ervan. Er zijn veel interessante en bevredigende carrières 
beschikbaar voor databaseprofessionals die bekend zijn met dataminingtechnieken. 


13.7.1 Unsupervised datamining 

Dataminingtechnieken kunnen we in twee brede categorieën onderverdelen: super- 
vised en unsupervised. De analisten stellen bij unsupervised datamining geen mo- 
del of hypothese op, voordat ze de analyse beginnen. De dataminingtechniek wordt 
in plaats daarvan op de gegevens toegepast en de resultaten worden bekeken. Na de 
analyse worden verklaringen en hypotheses opgesteld om de gevonden patronen te 
verklaren. 

Clusteranalyse is een veelgebruikte, unsupervised techniek. Hierbij worden sta- 
tistische technieken gebruikt voor het identificeren van groepen van entiteiten met 
soortgelijke kenmerken. Clusteranalyse wordt vaak gebruikt voor het zoeken van 
groepen in bestellingen en in demografische gegevens van klanten. Stel dat cluster- 
analyse twee heel verschillende groepen klanten identificeert: de ene groep heeft een 
gemiddelde leeftijd van 33 jaar, heeft minstens één pc en minstens één pda, rijdt in 
een dure terreinwagen en neigt ertoe dure spelapparaten voor kinderen te kopen. 
De tweede groep heeft een gemiddelde leeftijd van 64, bezit een vakantiehuis, speelt 
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golf en koopt dure wijnen. Stel dat de analyse ook opmerkt dat beide groepen merk- 
kleding voor kinderen kopen. 

Deze resultaten zijn uitsluitend verkregen door gegevensanalyse. Er is geen mo- 
del gebruikt om deze patronen en relaties te vinden. De analyse spreekt voor zich- 
zelf. Het wordt aan de analist overgelaten om achteraf hypotheses te vormen om uit 


te leggen waarom twee zo verschillende groepen beide merkkleding voor kinderen 
kopen. 


13.7.2 Supervised datamining 

Dataminers ontwikkelen bij supervised datamining een model voordat ze de analyse 
uitvoeren. Ze passen daarna statistische technieken op de gegevens toe om parame- 
ters van het model te schatten. Stel bijvoorbeeld dat marketingexperts bij een com- 
municatiebedrijf geloven dat het gebruik van belminuten voor mobiele telefoons in 
het weekend wordt bepaald door de leeftijd van de klant en door het aantal maanden 
dat de klant het mobiele telefoonabonnement heeft. Een datamininganalist zou dan 
een analyse uitvoeren die we een regressieanalyse noemen, om de coëfficiënten van 
de formule van dat model te bepalen. Een mogelijk resultaat is: 


Mobiel WeekendMinuten = 
12 + 17,5 * LeeftijdKlant + 23,7 * AantalMaandenVanAbonnement 


Zoals je in de statistiekles zult leren, is er heel wat vaardigheid nodig voor het inter- 
preteren van de kwaliteit van een dergelijk model. De regressietool stelt een formule 
op — het is echter van t-waarden, vertrouwensintervallen en gerelateerde statistische 
technieken afhankelijk of deze vergelijking een goede voorspelling kan leveren voor 
het toekomstige gebruik van mobiele telefoons. 


13.7.3 Drie populaire technieken voor datamining 

Beslisbomen, logistische regressie en neurale netwerken zijn drie populaire technie- 
ken voor datamining. Beslisboomanalyse of decision tree analysis classificeert klan- 
ten of andere entiteiten in twee of meer groepen, overeenkomstig de geschiedenis 
daarvan. 

Logistische regressie produceert vergelijkingen die waarschijnlijkheden leveren 
voor het optreden van bepaalde gebeurtenissen. Logistische regressie wordt bijvoor 
beeld vaak gebruikt voor het voorspellen van de kans op een donatie in een bepaalde 
tijdsperiode, op basis van eigenschappen van donoren. Een ander voorbeeld is het 
voorspellen van de kans dat klanten naar een andere leverancier overstappen, op ba- 
sis van de eigenschappen van klanten. 

Neurale netwerken zijn ingewikkelde statistische en wiskundige voorspellings- 
technieken. 

Deze drie technieken vereisen net als vrijwel alle dataminingtechnieken gespeci- 
aliseerde software. Enterprise Miner van SAS Corporation, Clementine van SPSS en 
Insightful Miner van Insightful Corporation zijn populaire dataminingproducten. 


516 


DATABASEVERWERKING VOOR BUSINESS INTELLIGENCE-SYSTEMEN 


Deze producten hebben allemaal voorzieningen voor het importeren van gegevens 
uit relationele databases en je zult, als databaseprofessional, misschien worden ge- 
vraagd gegevens voor te bereiden voor invoer in een dataminingproduct. Dit werk 
omvat vaak het samenvoegen van relaties in een enkel groot, plat bestand en het 
daarna filteren van de gegevens voor specifieke gegevensgevallen. Er wordt gewone 
SQL gebruikt voor het maken van dergelijke bestanden. 

Er is echter een dataminingtechniek die market basket-analyse heet, die mak- 


kelijk te implementeren is met alleen SQL. We zullen deze techniek hierna 
behandelen. 


13.7.4 Market basket-analyse 

Stel, je bent eigenaar van een duikwinkel en realiseert je op een gegeven moment dat 
een van je verkopers veel beter is dan de rest in het overreden van klanten om meer 
dingen te kopen. Al je verkopers kunnen een klant de dingen verkopen die ze willen 
hebben, maar deze ene verkoper is er bijzonder goed in hun nog meer dingen te ver- 
kopen. Je vraagt hem op een bepaald moment hoe hij dat doet. 

‘Dat is makkelijk’, zegt hij. ‘Ik vraag mezelf gewoon af wat het volgende product 
is dat ze zouden willen kopen. Als iemand een duikcomputer koopt, probeer ik niet 
hem zwemvinnen te verkopen. Als hij een duikcomputer koopt, dan is hij een dui- 
ker en heeft hij al zwemvinnen. Maar weet je, de displays van die duikcomputers 
zijn moeilijk te lezen. Een beter duikmasker maakt het makkelijker het display te 
lezen, waardoor je meer aan de duikcomputer hebt.” Een market basket-analyse is 
een dataminingtechniek voor het vinden van dergelijke patronen. Een market bas- 
ket-analyse laat zien welke producten de klanten vaak tegelijk kopen. Er kunnen 
diverse statistische technieken worden gebruikt voor het genereren van een mar- 
ket basket-analyse. We bespreken hier een techniek die met voorwaardelijke waar- 
schijnlijkheden werkt. 

Figuur 13-24 laat hypothetische gegevens zien van 1ooo transacties bij een duik- 
winkel. De eerste rij getallen onder elke kolom is het totale aantal transacties waarin 
het product in deze kolom voorkomt. De 270 in de eerste rij (Duikmasker) geeft bij- 
voorbeeld aan dat in 270 van de rooo transacties (onder andere) een duikmasker 
werd gekocht. De 120 onder Duikcomputer betekent dat in 120 van de 1ooo transac- 
ties een duikcomputer werd aangeschaft. 

We kunnen de getallen in de eerste rij gebruiken om te schatten hoe waarschijn- 
lijk het is dat een klant een artikel zal kopen. Van de rooo transacties omvatten er 
270 een duikmasker en we kunnen daarom schatten dat de waarschijnlijkheid dat 
een klant een duikmasker zal kopen 270/1000 of 0,27 is. We kunnen op dezelfde 
manier schatten dat de kans op het kopen van een zuurstoftank 200/1000 of 0,2 is 
en de kans op het kopen van zwemvinnen 280/10oo of 0,28. 

De resterende rijen in deze tabel geven aan hoe vaak er transacties voorkomen 
waar 2 artikelen bij betrokken zijn. De laatste kolom geeft bijvoorbeeld aan dat er 
5o transacties zijn voorgekomen die zowel een duikcomputer als een duikmas- 
ker omvatten, 30 transacties die een duikcomputer en een zuurstoftank omvatten, 
20 transacties met een duikcomputer en zwemvinnen, ro met een duikcomputer 
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Duikmasker et Wind en Duikcomputer 
1000 
transacties 200 | 280 130 IP 20 

Duikmasker 20 150 | 20 50 ij 

Zuurstoftank 20 40 30 | 30 | 

Zwemvinnen 150 40 î 10 60 20 el 

Gewichten 20 30 60 | 10 d 10 

Duikcomputer 50 30 20 [so |5 

Geen extra product — - - 5 \ 
| 


Support = W (A & B) Bijvoorbeeld: W (zwemvinnen & duikmasker) = 150 / 1000 = 0,15 
Confidence = W(A|B) Bijvoorbeeld: W (zwemvinnen | duikmasker) = 150 / 270 = 0,55556 
Lift = W (A | B) / W (A) Bijvoorbeeld: W (zwemvinnen | duikmasker) / W (zwemvinnen) 
= 0,55556 / 0,28 = 1,98 
Opmerking: W (duikmasker | zwemvinnen) / zwemvinnen) / W (duikmasker) 
=150/280/ 0,27 = 1,98 


Figuur 13-24 Voorbeeld van een market basket-analyse 


en gewichten, 5 met een duikcomputer en nog een duikcomputer (wat betekent dat 
de klant twee duikcomputers kocht) en 5 transacties met een duikcomputer en geen 
enkel ander product. 

Deze gegevens zijn interessant, maar we kunnen de analyse verfijnen door ex- 
tra factoren te berekenen. Marketingprofessionals definiëren support als de waar- 
schijnlijkheid dat 2 artikelen samen worden aangeschaft. Uit deze gegevens blijkt 
dat de support voor zwemvinnen en een duikmasker 15o van rooo is, of 0,15. De 
confidence wordt gedefinieerd als de waarschijnlijkheid dat een klant een bepaald 
product koopt, gegeven het feit dat hij of zij al een ander product heeft gekocht. De 
confidence voor zwemvinnen, gegeven dat de klant al een duikmasker heeft gekocht, 
is het aantal samen met een duikmasker gekochte zwemvinnen uit het totale aan- 
tal gekochte duikmaskers. De confidence is voor dit voorbeeld dus 150 van 270, of 
0,55556. De confidence dat een klant een zuurstoftank koopt, gegeven dat hij zwem- 
vinnen heeft gekocht, is 40 van 280, of 0,14286. 

De lift wordt gedefinieerd als de confidence, gedeeld door de basiswaarschijnlijk- 
heid dat een artikel wordt gekocht. De lift voor zwemvinnen, gegeven een duikmas- 
ker, is de waarschijnlijkheid dat een klant zwemvinnen koopt, gegeven dat hij een 
duikmasker heeft gekocht, gedeeld door de algehele waarschijnlijkheid dat de klant 
zwemvinnen koopt. Is de lift groter dan r, dan stijgt de waarschijnlijkheid dat een 
klant zwemvinnen koopt als hij een duikmasker koopt. Is de lift minder dan r, dan 
gaat de waarschijnlijkheid dat de klant zwemvinnen koopt omlaag als hij een duik- 
masker koopt. 

De lift voor zwemvinnen, gegeven de aankoop van een duikmasker, is 0,55556 
gedeeld door 0,28, dus 1,98, voor de gegevens uit Figuur 13-24. Dat betekent dat 
de kans dat een klant ook zwemvinnen koopt bijna verdubbelt als deze klant een 
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duikmasker koopt. De lift voor zwemvinnen, gegeven de aankoop van een duikcom:- 
puter, is 20 gedeeld door 120 (de confidence voor zwemvinnen, gegeven een duik- 
computer) gedeeld door 0,28 (de waarschijnlijkheid dat iemand zwemvinnen koopt 
— er kwamen zwemvinnen voor in 280 van de 1ooo transacties): zo gedeeld door 120 
is 0,16667 en 0,16667 gedeeld door 0,28 is 0,59525. De lift voor zwemvinnen, gege- 
ven een duikcomputer, is dus iets minder dan o,6, wat betekent dat de kans dat een 
klant zwemvinnen koopt, afneemt als deze klant een duikcomputer koopt. 

De lift is verrassend genoeg symmetrisch, zoals je in de laatste regel van Figuur 
13-24 ziet. Is de lift voor zwemvinnen — gegeven een duikmasker — 1,98, dan zal de 
lift voor een duikmasker — gegeven zwemvinnen — ook 1,98 zijn. 


13.7.5 SQL gebruiken voor market basket-analyse 

De belangrijkste producten voor datamining omvatten allemaal kenmerken en func- 
ties voor het uitvoeren van market basket-analyses. Deze producten zijn echter duur. 
Je kunt zo nodig een market basket-analyse uitvoeren met gewone SQL. 

Je ziet het belangrijkste SQL-statement in Figuur 15-26. Dit SQL-statement ver- 
werkt een relatie met de naam TRANS_DATA, die regel/artikelgegevens opslaat. 
Neem nu aan dat TRANS _DATA een kolom TransactionID heeft, die de identifier 
van een item in deze transactie opslaat. Een gegeven transactie kan meer items om- 
vatten. De sleutel van TRANS_ DATA is dus (TransactionlD, ltemID). TRANS_DATA 
bevat ook andere gegevens, zoals ItemPrice, Qty en ExtendedPrice, maar deze gege- 
vens zijn overbodig voor een market basket-analyse. We zullen ze hier negeren. 


W TwoItemBasket AS 

Tl.Item AS FirstItem, 

T2.Item AS SecondItem 

TRANS DATA Ld TRANS DATA T2 
Tl.TransactionID T1l.TransactionID 
T1l.ItemID T2.ItemID; 


Figuur 13-25 SQl-statement voor het maken van een korf met twee artikelen 


Het SQL-statement in Figuur 13-25 maakt een view van alle items die in twee of meer 
transacties samen zijn voorgekomen. Je kunt de support daarna berekenen in een 
view met behulp van het volgende statement: 


CREATE VIEW ItemSupport AS 
SELECT FirstItem, SecondItem, Count(*) as SupportCount 
FROM TwoltemBasket 
GROUP BY FirstItem, SecondItem; 


Deze view telt het aantal transacties waarin elk paar items voorkomt. Je kunt de sup- 
port voor de twee items verkrijgen door SupportCount in elke rij te delen door het 
totale aantal transacties. Je kunt daarna standaard-SQL gebruiken voor het bereke- 
nen van de confidence en de lift voor elk paar items. Zie oefening 53 tot en met 55. 
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Samenvatting 


Business intelligence- of Bl-systemen helpen managers en andere professionals bij 
het analyseren van huidige en voorgaande activiteiten en het voorspellen van toekom- 
stige gebeurtenissen. Er zijn twee hoofdtypen Bl-applicaties: rapportageapplicaties 
en dataminingapplicaties. Rapportageapplicaties voeren eenvoudige berekeningen 
uit op gegevens. Dataminingapplicaties maken gebruik van geavanceerde wiskun- 
dige en statistische technieken. 

Bl-applicaties verkrijgen gegevens uit drie bronnen: bedrijfsdatabases, uittreksels 
uit bedrijfsdatabases en aangekochte gegevens. Bl-systemen hebben soms een eigen 
DBMS, dat al dan niet hetzelfde is als het bedrijfs-DBMS. Figuur 13-2 toont de ken- 
merken van rapportage- en dataminingapplicaties. 

Om diverse redenen is het rechtstreeks lezen van bedrijfsdatabases niet haalbaar, 
behalve voor heel kleine databases. Het opvragen van bedrijfsgegevens kan de pres- 
taties van bedrijfssystemen op onacceptabele wijze verminderen. Bedrijfsgegevens 
hebben problemen die hun nut voor Bl-applicaties beperken. Het maken en onder- 
houden van Bl-systemen vereist bovendien programma's, voorzieningen en exper- 
tise die normaliter niet beschikbaar zijn voor een bedrijfsdatabase. Figuur 13-4 toont 
mogelijke problemen met bedrijfsgegevens. Vanwege deze problemen hebben veel 
organisaties ervoor gekozen datawarehouses en datamarts te maken en daar perso- 
neel aan toe te kennen. Datawarehouses extraheren bedrijfsgegevens, zuiveren deze 
en slaan de gereviseerde gegevens op in datawarehousedatabases. Organisaties kun- 
nen ook gegevens van gegevensleveranciers kopen en beheren. Datawarehouses on- 
derhouden metadata die de bron, indeling, aannames en voorwaarden beschrijven 
voor de gegevens die ze bevatten. Een datamart is een verzameling gegevens die klei- 
ner is dan wat er in een datawarehouse wordt bewaard en die een specifiek onderdeel 
of een specifiek functioneel gebied van het bedrijf aanspreekt. Het datawarehouse in 
Figuur 13-6 distribueert gegevens aan drie kleinere datamarts. Elke datamart voor- 
ziet in de behoeften van een ander aspect van het bedrijf. 

Het doel van een rapportagesysteem is het genereren van betekenisvolle infor- 
matie op basis van allerlei datasources en het op tijd leveren van deze informatie 
aan de juiste gebruikers. Rapporten worden geproduceerd door te sorteren, te filte- 
ren en te groeperen en door eenvoudige berekeningen uit te voeren op de gegevens. 
RFM-analyse is een typische rapportageapplicatie. Klanten worden gegroepeerd en 
geclassificeerd overeenkomstig hoe recentelijk ze een bestelling plaatsten (R), hoe 
vaak ze bestelden (frequency — F) en hoeveel geld ze aan bestellingen besteedden 
(money — M). Het resultaat van een RFM-analyse bestaat uit drie scores. De scores 
reiken bij een gebruikelijke analyse van 1 tot 5. Een RFM-score van {1 1 4} geeft aan 
dat de klant recentelijk heeft besteld, dat hij vaak bestelt maar dat hij geen dure din- 
gen koopt. Een RFM-rapport kan worden gemaakt met behulp van eenvoudige SQL. 
Figuur 13-10 en Figuur 13-11 tonen opgeslagen procedures voor het berekenen van 
deze scores. 

Een RFM-rapport moet goed voorbereid en aan de juiste gebruikers worden ge- 
leverd, willen de RFM-gegevens waarde aan de organisatie toevoegen. Figuur 13-13 
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toont de onderdelen van een modern rapportagesysteem. Rapportagesystemen on- 
derhouden metadata die de drie basisrapportagefuncties ondersteunen: het schrij- 
ven, beheren en afleveren van rapporten. De metadata omvatten informatie over 
gebruikers, gebruikersgroepen en rapporten en gegevens over welke gebruikers 
wanneer en via welke media welke rapporten moeten krijgen. Zoals je in Figuur 
13-14 ziet, variëren de rapporten afhankelijk van het type, het medium en de modus. 

OnLine Analytical Processing (OLAP) is een algemene categorie van rapportage- 
applicaties die het gebruikers mogelijk maakt rapporten dynamisch te herstructure- 
ren. Een maateenheid is het gegeven waarin je geïnteresseerd bent. Een dimensie is 
een kenmerk van een maateenheid. Een OLAP-kubus is een indeling van maateen- 
heden en dimensies. Gebruikers kunnen met OLAP omlaag boren en de volgorde 
van de dimensies verwisselen. Sommige organisaties gebruiken afzonderlijke com- 
puters als OLAP-servers, vanwege de hoge verwerkingseisen. 

Datamining is het toepassen van wiskundige en statistische technieken voor het 
zoeken van patronen en relaties en voor het classificeren en voorspellen. Datamining 
is in de afgelopen jaren opgekomen vanwege de samenkomst van de in Figuur 13-23 
getoonde factoren. 

Analisten stellen bij unsupervised datamining geen modellen of hypothesen op 
voordat de analyse wordt uitgevoerd. De resultaten worden uitgelegd nadat de ana- 
lyse is voltooid. Bij supervised technieken worden hypothesen opgesteld en uitge- 
probeerd voordat de analyse wordt uitgevoerd. Beslisbomen, logistische regressie en 
neurale netwerken zijn drie populaire technieken voor datamining. 

De meeste dataminingtechnieken vereisen speciale software. Er is echter een 
dataminingtechniek die kan worden uitgevoerd met alleen SQL: de market basket- 
analyse. De support voor twee producten is in de terminologie van de market basket- 
analyse de frequentie waarmee deze producten samen in een transactie voorkomen. 
De confidence is de voorwaardelijke waarschijnlijkheid dat een item wordt gekocht, 
gegeven het feit dat een ander item al is gekocht. De lift is de confidence gedeeld door 
de basiswaarschijnlijkheid dat een item wordt gekocht. 

Een SQL-joinstatement kan worden geschreven om een view te maken die pro- 
ducten toont die samen in een transactie zijn voorgekomen. Deze view kan dan 
worden verwerkt om de support te berekenen. De view voor de support kan daarna 
worden verwerkt om de confidence en de lift te berekenen. 


Belangrijke termen 


alert datawarehouse 

beslisboom datawarehouse metadata-database 
business intelligence (BĲ)-systeem decision support system (DSS) 
click-stream data decision tree 

clusteranalyse digital dashboard 

confidence dimensie 

datamart dirty data 

dataminingapplicatie drill down 
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dynamisch rapport 

Extract, Transform, and Load (ETL) 
System 

F-score 

lift 

logistische regressie 

maateenheid 

market basket-analyse 

measure 

M-score 

neuraal netwerk 

OLAP-kubus 

OLAP-rapport 

OLAP-server 

OnLine Analytical Processing (OLAP) 

pullrapport 


pushrapport 
queryrapport 

rapport leveren 
rapport schrijven 
rapportagesysteem 
rapportbeheer 
regressieanalyse 
RFM-analyse 

R-score 

SQL Top... Percent 
statisch rapport 
supervised datamining 
support 

unsupervised datamining 
webportaal 


Oefeningen 
1. Wat zijn Bl-systemen? 
2. Waarin verschillen Bl-systemen van transactieverwerkingsystemen? 
3. Noem en beschrijf de twee hoofdcategorieën van BlI-systemen. 
4. Wat zijn de drie bronnen van gegevens voor BlI-systemen? 
5. Leg uit wat het verschil is tussen het verwerken van rapportageapplicaties en het 
verwerken van dataminingapplicaties. 
6. Geef drie redenen waarom het rechtstreeks lezen van bedrijfsgegevens niet 
haalbaar is voor Bl-applicaties. 
7. Vat samen welke problemen van bedrijfsdatabases het nut van deze databases 
beperken voor Bl-applicaties. 
8. Wat zijn dirty data? Hoe ontstaan dirty data? 
9. Waarom is de servertijd niet nuttig voor op het web gebaseerde Bl-applicaties 
voor orderinvoer? 
ro. Wat zijn click-stream data? Hoe worden deze gebruikt in Bl-applicaties? 
in. Waarom zijn datawarehouses nodig? 
12. Waarom beschrijft de auteur de gegevens in Figuur 13-5 als ‘angstaanjagend’? 
13. Geef voorbeelden van metadata in een datawarehouse. 
14. Leg uit wat het verschil is tussen een datawarehouse en een datamart. Gebruik 
de analogie van een bevoorradingsketen. 
15. Noem het doel van een rapportagesysteem. 
16. Waar staan de letters RFM voor in RFM-analyse? 
17. Beschrijf in algemene termen hoe een RFM-analyse wordt uitgevoerd. 
18. Leg uit wat de kenmerken zijn van klanten met de volgende RFM-scores: {11 5}, 
sx}, (55 5} {255} 512} (113) 
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Welke rol speelt de tabel CUSTOMER_RFM in de RFM-analyse in Figuur 13-9, 
Figuur 13-10 en Figuur 13-11? Welke rol speelt de tabel CUSTOMER_R? 
Leg uit wat het doel is van het volgende SQL-statement uit Figuur 13-11: 


INSERT INTO CUSTOMER R (CustomerID, MostRecentOrderDate) 
(SELECT CustomerID, Max (TransactionDate) 
FROM CUSTOMER _SALES 
GROUP BY CustomerID); 


Leg uit wat het doel van het volgende SQL-statement uit Figuur 13-11 is en leg uit 
hoe dit statement werkt: 


UPDATE CUSTOMER _R 


SET R_Score = 1 

WHERE CustomerID IN 
(Select Top 20 Percent CustomerID 
FROM CUSTOMER _R 


ORDER BY MostRecentOrderDate DESC) 
GROUP BY CustomerID); 


.„ Leg uit wat het doel van het volgende SQL-statement uit Figuur 13-11 is en leg uit 


hoe dit statement werkt: 


UPDATE CUSTOMER _R 


SIE Re Score = 2 

WHERE CustomerID IN 
(Select Top 25 PERCENT CustomerID 
FROM CUSTOMER_R 


WHERE R_Score IS NULL 
ORDER BY MostRecentOrderDate DESC); 


Schrijf een SQL-statement voor het opvragen van de tabel CUSTOMER _RFM 
en het weergeven van de CustomerlD-waarden van alle klanten met een RFM- 
score van {5 1 1} of {4 1 1}. Waarom zijn deze klanten belangrijk? 

Noem en beschrijf het doel van de belangrijkste onderdelen van een rapportage- 
systeem. 

Wat zijn de hoofdfuncties van een rapportagesysteem? 

Vat de soorten rapporten samen die we in dit hoofdstuk beschreven. 

Beschrijf de diverse soorten media die worden gebruikt voor het afleveren van 
rapporten. 

Vat de rapportagemodi samen die we in dit hoofdstuk beschreven. 

Noem drie taken voor het schrijven van rapporten. 

Noem de hoofdtaken voor het beheren van rapporten. Leg uit welke rol rapport- 
metadata spelen in het rapportenbeheer. 
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42. 


43. 
44. 
45. 


Beschrijf de hoofdtaken voor het afleveren van rapporten. 

Waar is OLAP de afkorting van? 

Wat is het onderscheidende kenmerk van OLAP-rapporten? 

Definieer maateenheid, dimensie en kubus. 

Bedenk zelf een voorbeeld (dat niet in dit boek voorkomt) van een maateenheid, 
twee aan je maateenheid gerelateerde dimensies en een kubus. 


„ Wat is omlaag boren (drill down)? 


Noem twee aspecten waarin het OLAP-rapport in Figuur 13-20 verschilt van dat 
in Figuur 13-21. 
Wat is het doel van een OLAP-server? 


. Definieer datamining. 


. Leg uit wat het verschil is tussen unsupervised en supervised datamining. 


Bedenk zelf voorbeelden (die niet in dit boek voorkomen) van unsupervised en 
supervised datamining. 


Leg de twee groepen uit in de resultaten van de clusteranalyse die we in para- 
graaf 13.7.1 beschrijven. 

Noem drie populaire dataminingtechnieken . 

Wat is het doel van logistische regressie? 

Wat is het doel van een neuraal netwerk? 


Gebruik de gegevens uit Figuur 13-24 voor het beantwoorden van vraag 46 tot en 
met 51. 


46. 
47. 


Wat is de waarschijnlijkheid dat iemand een zuurstoftank koopt? 


Wat is de support voor het kopen van een zuurstoftank en zwemvinnen? Wat is 
de support voor het kopen van twee zuurstoftanks? 


48. Wat is de confidence voor zwemvinnen, gegeven dat er een zuurstoftank is 
gekocht? 

49. Watis de confidence voor een tweede zuurstoftank, gegeven dat er een zuurstof- 
tank is gekocht? 

so. Wat is de lift voor zwemvinnen, gegeven dat er een zuurstoftank is gekocht? 

st. Wat is de lift voor een tweede zuurstoftank, gegeven dat er een zuurstoftank is 
gekocht? 

Projectvragen 


52. Gebruik de code uit Figuur 13-11 als voorbeeld en schrijf de procedures 


Calculate_F en Calculate._M die worden aangeroepen vanuit de opgeslagen pro- 
cedure Calculate_RFM uit Figuur 13-10. 


Gebruik SQL Server, Oracle of MySQL voor vraag 53 tot en met 55. 
53. Schrijf een opgeslagen procedure voor het berekenen van de support. Gebruik 


de in paragraaf 13.7.5 beschreven tabel TRANS DATA en de in Figuur 13-25 ge- 


toonde view. Breng je resultaten onder in een view met de naam SupportView. 
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54. Schrijf een opgeslagen procedure voor het berekenen van de confidence. Ge- 
bruik de in paragraaf 13.7.5 beschreven tabel TRANS_DATA en de SupportView. 
Breng je resultaten onder in een view met de naam Confidence View. 

55. Schrijf een opgeslagen procedure voor het berekenen van de lift. Gebruik de 
in paragraaf 13.7.5 beschreven tabel TRANS-_ DATA voor het berekenen van on- 
voorwaardelijke waarschijnlijkheden en gebruik de ConfidenceView voor de 
confidence. 


Marcia’s Chemische Reiniging 


Neem aan dat Marcia een database gebruikt die de volgende drie tabellen omvat: 


CUSTOMER (CustomerlD, Phone, E-mail, FirstName, LastName) 

INVOICE (InvoiceNumber, Date, CustomerID, Subtotal, Tax, Total) 
INVOICE ITEM (InvoiceNumber, ItemNumber, CustomerlD, 
Quantity, Service, UnitPrice, ExtendedPrice) 


(INVOICE_ITEM.Service is een externe sleutel voor de tabel SERVICE. De tabel 

SERVICE is echter niet nodig voor deze oefeningen.) 

A. Beschrijf hoe een RFM-analyse van nut kan zijn voor Marcia's bedrijf. 

B. Gebruik de vier tabellen uit Figuur 13-9 voor het schrijven van een reeks opgesla- 
gen procedures voor het berekenen van een RFM-analyse op basis van Marcia's 
gegevens. 

C. Geef SQL voor het verwerken van de in je antwoord op B gemaakte tabel, voor 
het weergeven van de namen en e-mailgegevens van alle klanten met een RFM- 
score van {5 1 1} of (4 1 1}. 

D. Beschrijf in algemene termen hoe een market basket-analyse kan worden toege- 
past op de items in een reinigingsfactuur. 

E. Gebruik de instructies in vraag 53 tot en met 55 voor het schrijven van opgesla- 
gen procedures voor het uitvoeren van een market basket-analyse op de items in 
een reinigingsfactuur. 


Importbedrijf Morgan 


Er is geen voor de hand liggende manier om de tabellen die we voor Importbedrijf 
Morgan gebruikt hebben, voor een RFM- of een market basket-analyse te gebruiken 
— dat wil zeggen: niet voor Morgan. Kijk echter eens vanuit het gezichtspunt van een 
exporteur naar de volgende drie tabellen: 


SHIPMENT (ShipmentID, ShipDate, ShipperName, 
ShipperInvoiceNumber, Origin, Destination) 
SHIPMENT ITEM (ShipmentID, PurchaselD, InsuredValue) 


SHIPPER (ShipperName, Phone, Fax, E-mail, 
Contact) 
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We kunnen de structuur van een database maken die klanten en door ons verzonden 


ladingen en artikelen zal registreren door SHIPPER door CUSTOMER te vervangen. 
De gewijzigde tabellen zijn: 


SHIPMENT (ShipperInvoiceNumber, ShipDate, CustomerID, Origin, 
Destination, Subtotal, Tax, Total) 

SHIPMENT ITEM (ShipperlInvoiceNumber, ItemNumber, ShippingCost) 

CUSTOMER (CustomerID, CustomerName, Phone, Fax, E-mail, Contact) 


Hierbij is CustomerlD een surrogaatsleutel voor de klantengegevens. Gebruik deze 
aangepaste tabellen voor het beantwoorden van de volgende vragen: 


A. Beschrijf hoe een RFM-analyse van nut kan zijn voor de exporteur. 

B. Gebruik de vier tabellen uit Figuur 13-9 voor het schrijven van een reeks opge- 
slagen procedures voor het berekenen van een RFM-analyse voor verzendingen. 

GC. Geef SQL voor het verwerken van de in je antwoord op B gemaakte tabel, voor 
het weergeven van de namen en e-mailgegevens van alle klanten met een RFM- 
score van {5 1 1} of {4 1 1}. 

D. Beschrijf in algemene termen hoe een market basket-analyse kan worden toege- 
past op de items in een lading. 

E. Gebruik de instructies in vraag 53 tot en met 55 voor het schrijven van opgesla- 
gen procedures voor het uitvoeren van een market basket-analyse op de items in 
een lading. 
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Bijlage A 
Inleiding in 
Microsoft Access 2007 


Deze bijlage geeft een inleiding in Microsoft Access 2007. Na het lezen van deze 
bijlage kun je tabellen en relaties tussen tabellen maken, de tabellen met gegevens 
vullen en eenvoudige formulieren en query’s maken. Er wordt hier maar een fractie 
van de mogelijkheden van Access besproken. Deze bijlage concentreert zich op de 
voorzieningen en functies voor het maken van tabellen, zodat je Access kunt gebruiken 
voor het oefenen van het schrijven van SQL-statements, zoals dat in hoofdstuk 2 wordt 
besproken. 

De instructies en schermafbeeldingen in deze bijlage betreffen de Nederlandstalige 
versie van Microsoft Access 2007. De overeenkomstige opdrachten van de Engelstalige 
versie van Access 2007 staan tussen haakjes achter de Nederlandse opdrachten. De 
opdrachten en schermweergaven kunnen lichtelijk verschillen als je een andere ver- 


sie van Access gebruikt, maar je zou deze toelichting zonder moeite moeten kunnen 
volgen. 
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A1 Het ontwerp van de voorbeelddatabase 


Bij wijze van voorbeeld maak je de tabellen STUDENT, VAK en CIJFER uit hoofd- 
stuk 1, die je in Figuur A-r ziet. Dat zijn dezelfde drie tabellen als in Figuur 1-4. Elke 
tabel bestaat uit een aantal kolommen, waarvan je de namen in Figuur A-1 ziet. 


STUDENT CIJFER JAK 
Y Studentnummer Cijfer Z Vaknummer 
Achternaam Y Studentnummer Vaknaam 
Voornaam Y vaknummer Trimester 


Emailadres Sectie 


Figuur A-1 


Een andere manier om deze tabellen weer te geven is door middel van een 
databaseschema: 


STUDENT (Studentnummer, Achternaam, Voornaam, Emailadres) 
CIJFER (Cijfer, Studentnummer, Vaknummer) 
VAK (Vaknummer, Vaknaam, Trimester, Sectie) 


In zo’n schema schrijf je de tabelnamen met uitsluitend hoofdletters, de namen van 
de kolommen beginnen met een hoofdletter. 


Elke tabel bevat een sleutel: een of meer kolommen die een rij op een unieke ma- 
nier identificeren. In het schema is de sleutel onderstreept, in Figuur A-1 staat er een 
sleuteltje bij de kolomnaam. Sleutels zijn van groot belang omdat de waarde van een 
sleutel een unieke rij in de tabel identificeert. De sleutel van STUDENT is Student- 
nummer. Dat betekent dat een bepaalde waarde van Studentnummer, bijvoorbeeld 
400, als hij in de tabel STUDENT voorkomt, dan in precies één rij voorkomt. De 
sleutel van VAK is Vaknummer. 

Er is geen afzonderlijke kolom die een sleutel kan zijn voor de tabel CIJFER. Er 
kunnen meer cijfers worden geregistreerd voor een student en Studentnummer is 
dus geen sleutel op zichzelf. Een vak zal veel studenten hebben en Vaknummer kan 
dus ook de sleutel niet zijn. Als we echter aannemen dat een student hetzelfde vak 
maar eenmaal volgt, dan is de combinatie (Studentnummer, Vaknummer) wel een 
sleutel. We zullen dat in deze database aannemen. Omdat Studentnummer en Vak- 
nummer sleutels zijn afkomstig uit een andere tabel heten ze externe sleutels (of 
vreemde sleutels of foreign keys). In het schema zijn de vreemde sleutels cursief 


afgebeeld. 
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Samenvattend: Studentnummer is de sleutel van STUDENT, Vaknummer is de 


sleutel van VAK en de combinatie (Studentnummer, Vaknummer) is de sleutel van 
CIJFER. 


A2 Een database met een tabel maken 


We maken de database met de tabellen zoals die in de vorige paragraaf staan. 
* Open Microsoft Access 2007 


In het openingsvenster verschijnt Aan de slag met (Getting Started with) Microsoft 
Office Access en daaronder zie je de knop Lege database (Blank Database). 


+ _ Klik op Lege database (Blank Database) 

* Voer in het vak een naam in voor de database: Student-Vak-Cijfer.accdb, zie 
Figuur A-2 

+ Klik op Maken (Create) 


> 
| 
3 
ei 
A] 
4 


Lege database 
ben marcich Offce Accense zanven 
bestaande gegevens of objecten maben. 
Bestandsnaam 
Sapiens van ter mec pe} 
Len tabel maken C Deamers and eangtP Mp doamertenì 


Là Sassen | CE 
23 


benoeten 


Heer op Oftce Ontne 
Doventoads | Bamng | Sjablenen 


Figuur A-2 


Er verschijnt een venster met een nieuwe tabel met de naam Tabelr. Deze tabel wordt 
getoond in de zogeheten Gegevensbladweergave (Datasheet View). Met behulp van 
deze weergave kun je snel gegevens invoeren, maar het eerste wat wij nu gaan doen 


is het ontwerp voor een nieuwe tabel STUDENT maken. Dat doe je in de zogeheten 
Ontwerpweergave (Design View). 
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. Klik op Weergave (View) links in de werkbalk 
, Geef de tabel de naam STUDENT 


Het volgende venster dat verschijnt is een formulier dat je kunt invullen om de ko- 
lommen in je tabel te definiëren. In plaats van het woord kolom gebruikt Access het 
woord veld (field). 


+ Typ Studentnummer als de eerste Veldnaam (Field Name) en druk op Tab om 
naar het invoervak Gegevenstype (Data Type) te gaan 
* Open de keuzelijst in dit vak en selecteer Numeriek (Number). 


Kijk nu eens naar het onderste deel van het formulier, onder de kop Veldeigenschap- 
pen (Field Properties). Access heeft Lange integer (Long Integer) gekozen voor de 
Veldlengte (Field Size). Dat is ook wat we willen en je hoeft verder dus niets meer te 
doen om deze kolom te definiëren. 


De derde kolom in het formulier voor het maken van een tabel is Beschrijving (Des- 
eription). Je kunt hier opmerkingen over je kolom invoeren. Access zal elk hier inge- 
voerd commentaar negeren. We zullen Beschrijving niet gebruiken in deze bijlage. 


+ Vul nu nog drie rijen van dit formulier in voor de kolommen Achternaam, Voor- 
naam en e-mailadres 


Deze kolommen hebben het gegevenstype Tekst (Text) en de Veldlengte 5o. De veld- 


lengte so kun je veranderen bij Veldeigenschappen. De standaardinstelling van 
Access is 255. 


Je definieert de sleutel van de tabel door de rij Studentnummer te selecteren en 


dan op het sleutelicoon in de werkbalk te klikken. Er komt dan een sleuteltje voor 
Studentnummer te staan. 


Als het goed is ziet het venster er nu uit als in Figuur A-3. 
+ Klik op de knop Opslaan (Save) om de tabel op te slaan 


Als je wilt kun je de andere twee tabellen nu ook maken, via de tab Maken (Create) en 
dan de knop Tabelontwerp (Table Design). We zullen dat hier echter nog niet doen — 
we zullen in plaats daarvan eerst gegevens aan de tabel STUDENT toevoegen en dan 
de andere twee tabellen maken. 


A3 _ Gegevens toevoegen aan een tabel 


Je kunt gegevens aan de tabel STUDENT toevoegen in de Gegevensbladweergave 
(Datasheet View). Doe dat als volgt: 
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F5 En zr = ®_Student-vok-Cuter : Database (Access 2007) - M. _ Hulpmiddelen voor tabellen 
Bij U àl 
md Stut kak Externe aegevens Hulpmiddet, or databases Ontwerpen Ki 
il @) = u d ki _ 
EE | ®, | N 58 Ryen invoegen N  Br4 
| ! ’ ! Kz 


Új …… 


5 Í E_ Rijen verwijderen 
Weergave Prmaire Opbourtond heregt Eigenschappenvenster Indexen 
- sleutei teste zl Opzoekkolom 


vreergaven Extra 


Vieergsven verbergen 


Alle tabellen Ti | Z] STUDENT \ 


Veldnaam Gegevenstype 


STUDENT Beschrijving 
| IA student: Tabel |Y» studentnumfner Numeriek 
Achternaam Tekst 
| Voornaam Tekst 


ij Emailadres Tekst 


Veldeigenschappen 


Algemeen Opzoeken | 


Veldiengte Lange integer IN | 
| 
Aantal decimalen Automatisch | | 
Invoermasker : | 
Bijschuft | | 
Standaardwaarde LN! De maxmumlengte voor veldnamen is 64 | 

| Vakdatieregel | | tekens, inclusief spaties. Oruk op F1 voor Heip 
|| valdatietekst | over veldnamen. | 
Vereist Nee Î 
Geindexeerd Ja (Geen duplicaten) | 
‚{ Infolabels Hi 
| Teksturtlijning Algemeen | 
| 


Ontwerpweergave. F6 = Schakelen tussen deelvensters. FL « Help, 


Figuur A-3 De voltooide definitie van de tabel STUDENT 
+ Klik met de rechtermuisknop op de tab STUDENT 
* Kies in het menu dat verschijnt Gegevensbladweergave (Datasheet View) 


Voer nu de gegevens in zoals die in Figuur A-4 staan. Met de tabtoets kun je naar de 
volgende kolom (veld) springen. 


STUDENT 
Voornaam 


E-mailadres 
Kok@OnzeU.edu 
Lerik@OnzeU.edu 
Louis Holman@OnzeU.edu 


Groen@OnzeU.edu 


Studentnummer Achternaam 
100 Kok 
200 Lerik 
300 Holman 
400 Groen 


Figuur A-4 


Je kunt in de Gegevensbladweergave niet alleen gegevens toevoegen, maar ook wijzi 
gen en verwijderen. Je wijzigt gegevens door de cursor simpelweg in de cel te plaat- 
sen die je wilt wijzigen en de gegevens daarna te veranderen. De wijziging zal in de 
database worden uitgevoerd zodra je naar een andere cel gaat. Je verwijdert gegevens 
door de rij die je wilt verwijderen te selecteren door in de meest linkse kolom vlak 
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voor die rij te klikken. Druk daarna op Delete. De benaming die Access gebruikt voor 
rij is record. 


A4 De tabellen VAK en CIJFER maken 
De tabel VAK maak je als volgt: 


+ Klik op de tab Maken (Create) 
* Klik op de knop Tabelontwerp (Table Design) 


De eigenschappen van de kolommen van de tabel VAK zie je in Figuur A-5. 


Kolomnaam (veld) Gegevenstype [veldeigenschap | Primaire sleutel 
Vaknummer Numeriek | Lange integer 


8 Ja n 
Vaknaam | Tekst \veldlengte 258 n Tree . 
Trimester | Tekst Veldlengte 12 [nee ä E 
Sectie | Numeriek | Integer | Nee E 


Figuur A-5 De kolommen van de tabel VAK 


+ Breng de gegevens uit Figuur A-5 over in Access 
* Klik op de knop Opslaan (Save) en geef de tabel de naam VAK 


Je kunt nu gegevens in de tabel VAK invoeren. Doe dat als volgt: 


* Klik met de rechtermuisknop op de tab VAK 
* Kies in het menu Gegevensbladweergave (Datasheet View) 


Voer de gegevens in zoals die in Figuur A-6 staan. 


30 Scheikunde 1 ros | | 
40 Jacountingt [ea | 1 | 


Figuur A-6 De gegevens voor de tabel VAK 


Volg nu dezelfde procedure als hierboven voor het maken van de tabel CIJFER. 
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De eigenschappen van de kolommen van de tabel CIJFER zie je in Figuur A-7. 


| Kolomnaam (veld) | Gegevenstype (veldeigenschap - 3 ______T primaire sleutel 
„Studentnummer Numeriek | Lange integer li Ene samengesteld 
\Vaknummer | Numeriek _| Lange integer ______|a, samengesteld 

| Cijfer Numeriek | Enkele precisie (Single precision) [Nee meal. $ 


_| Aantal decimalen: 2__ E | 


Figuur A-7 De kolommen van de tabel CIJFER 


Breng de gegevens uit Figuur A-7 over in Access 

Zoals we hebben gezien bestaat de primaire sleutel van CIJFER uit de combina- 
tie van Studentnummer en Vaknummer, het is een samengestelde sleutel. Om in 
Access een samengestelde sleutel in te stellen moet je eerste beide rijen selecteren. 
«Klik in het vakje vlak voor Studentnummer om deze rij te selecteren 


* Houd Ctrl ingedrukt en klik in het vakje voor Vaknummer om ook deze rij te 
selecteren 


«Klik nu op de knop Primaire Sleutel in de werkbalk. Als deze knop niet zichtbaar 
is, klik dan eerst op het tabblad Ontwerpen (Design) 

Als het goed is verschijnen er sleuteltjes voor beide rijen. 

+ Klik op de knop Opslaan (Save) en geef de tabel de naam CIJFER 


Voeg nu gegevens aan de tabel CIJFER toe. Doe dat als volgt: 


* Klik met de rechtermuisknop op de tab CIJFER 
* Kies in het menu Gegevensbladweergave (Datasheet View) 


Voer de gegevens in zoals die in Figuur A-8 staan. 


CIJFER 
Studentnummer Vaknummer 
100 10 
100 | 40 
200 | 20 
L 300 | 30 
400 40 
400 50 
Figuur A-8 
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A5 Relaties maken 


De tabellen die we in de voorgaande paragrafen hebben gemaakt zijn nog niet aan 
elkaar gerelateerd. Het zijn drie losse tabellen. Relaties tussen tabellen maak je in 
Access via de tab Hulpmiddelen voor databases (Database Tools) en daarna de knop 
Relaties (Relationships). Om relaties te kunnen maken moet je eerst de tabellen slui- 
ten (niet de databasel). 


+ Klik met de rechtermuisknop op een van de tabs met de naam van een tabel en 
kies in het menu Alles sluiten (Close All) 


Bewaar de eventueel gemaakte wijzigingen als Access daar om vraagt. 


De tabellen zijn nu gesloten, maar aan de linkerkant zie je de namen van de tabel- 


len waaruit deze database bestaat. Je kunt een tabel weer openen door op zijn naam 
dubbel te klikkn. 


We gaan nu de relaties tussen de tabellen aanbrengen. 


+ Klik op de tab Hulpmiddelen voor databases (Database Tools) 
+ Klik op de knop Relaties (Relationships) 


Er verschijnt een dialoogvenster met de naam Tabel weergeven (Show Table). 
«Klik in dit venster op STUDENT en klik op de knop Toevoegen (Add) 
*_Klik in dit venster op CIJFER en klik op de knop Toevoegen (Add) 

+ Doe hetzelfde voor VAK 


* Klik op de knop Sluiten (Close) om het dialoogvenster te sluiten 


Je ziet nu de drie tabellen weergegeven door middel van drie venstertjes. Je kunt de 
vensters desgewenst verslepen. 


We gaan nu Studentnummer van STUDENT relateren aan Studentnummer in 
CIJFER. Je maakt deze relatie door Studentnummer van STUDENT naar Student- 
nummer in CIJFER te slepen en deze daar los te laten. 

‚Sleep Studentnummer van STUDENT naar Studentnummer in CIJFER 

Access opent het dialoogvenster Relaties bewerken (Edit Relationships). 

‚ _Zeteen vinkje bij Referentiële integriteit afdwingen (Enforce Referential Integrity) 
Er wordt hierdoor een referential integrity constraint gemaakt, een bespreking daar- 
van staat in hoofdstuk 3. Een dergelijke constraint zal garanderen dat elke waarde 


voor Studentnummer die in CIJFER wordt ingevoerd overeen zal komen met een 
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bestaande waarde van Studentnummer in STUDENT. Mocht dat niet het geval zijn, 
dan zal Access een foutmelding leveren en het invoegen van de niet overeenkomen- 
de waarde voor Studentnummer in CIJFER verbieden. Hierdoor wordt voorkomen 
dat er cijfers worden ingevoerd met een niet bestaand studentnummer. 


«Klik in het dialoogvenster op de knop Maken (Create) om de relatie op te slaan 
Maak de relatie tussen VAK en CIJFER op dezelfde manier: 


+ _ Sleep Vaknummer uit VAK naar Vaknummer in CIJFER en laat deze daar los 
+ Vink Referentiële integriteit afdwingen aan en klik op Maken 


Beide relaties zijn nu gemaakt. Je ziet het uiteindelijke resultaat in Figuur A-r. 
Je kunt de eigenschappen van een relatie controleren door op de relatielijn te 
rechtsklikken en Eigenschappen (Properties) te selecteren. 


«Sluit het relatievenster en sla de wijzigingen op als daarom wordt gevraagd 
Open nu bij wijze van experiment de tabel CIJFER. 
+ Klik aan de linkerkant van het scherm dubbel op CIJFER: Tabel 


Probeer nu een rij met Studentnummer 5 aan CIJFER toe te voegen, om te zien hoe 
de referential integrity constraint werkt. Je zult een foutmelding krijgen als je Refe- 
rentiële integriteit afdwingen hebt aangevinkt in het relatiedialoogvenster. 


A6 _Query’s maken 


Een query is een vraag die je stelt aan een database. In Access kun je op twee ver- 
schillende manieren query’s maken. De eerste methode is met behulp van SQL, en 
de tweede is via Query by Example (QBE). SQL wordt in hoofdstuk 2 besproken, in 
deze bijlage laten we zien hoe QBE werkt. 


Query's zijn gebaseerd op een of meer tabellen. Laten we beginnen met een eenvou- 


dige query die om de voor- en achternamen van alle studenten uit de tabel STUDENT 
vraagt. 


* Klik op het tabblad Maken (Create) en kies Queryontwerp (Query Design) 

* Klik in het dialoogvenster dat verschijnt op de tabel STUDENT en klik op Toevoe- 
gen (Add) 

* _ Sluit het dialoogvenster 


«Klik in de onderste helft van het scherm achter het pijltje bij Veld (Field) en kies 
Voornaam uit de keuzelijst (zie Figuur Á-9) 
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C° DD as B Studeervakteter Database (AMEN: SCOT) - IA pgipmiadeien voor awe 5 es x 
ee) 
{Sar Maten Eaterne gegevens Muipmiggelen voor catabnies Ontwerpen w 
En 4 Be A Ettema op Femme 
nd 2108 HH rmommen verwijderen 8 rabensmen 
wieergase Uitvoeren Tabel Ët Tetaten 
re PT AL weergeven EN WlResurst Aes Ip Parameter: 
Reruitaten at weerzevenvverdengen 
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STUDENT : ee EN pe 
STUDER 
DD stvorn: raber í ed [ 
VAK «| 7 studentnunmer 
DD vans rape | Achteraan 
CUTER dl : voornaam 
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Crteris: 
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NIJMLOCK ID B Asa 


Figuur A-9 Het maken van een query 


* Klik in het vak rechts van Voornaam, klik in dat vak op het pijltje en kies Achter- 
naam uit de lijst 


Het scherm ziet er nu uit als in Figuur A-ro. 


Ca Dr OF Student vak-Cufer ; Database (Access 2007) - M.__ Huiprmadeien voor quen’s Ee: 
- Start Maten Kstemnegegesens _ Muipmadeien voor datatases Ontwerpen w 


T ) ie) AD 23 Je Y eiommen meegen D 5 Bgersnappensenster 
B roromnen verwyderen Tabe’ 


Tabel ú 
PTA meergeven EN SjlResctaat are - 


Weergsee Uitvoeren 


Reuutaten 


STUDENT 


9 Studentnummer 
Achternaam 
Voornaam 


NEENEES Emacadres 
: Tabel 


Figuur A-10 


« Klik in de werkbalk op het rode uitroepteken om de query te laten uitvoeren 
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De uitvoer ziet er uit als in Figuur A-rr. 


Query1 ] 
[ Voornaam | Achternaam | 
[sam | Kok | 
| Marcia | Lerik 

|Louis | Holman | 
\Gerda Groen | 


Figuur A-11 Het resultaat van de query 


Je kunt de query opslaan en hem een duidelijke naam geven, zodat je hem later weer 
kunt gebruiken. 


Op de achtergrond maakt Access gebruik van SQL om de query uit te voeren. Je kunt 
het betreffende SQL-statement zien door te rechtsklikken op de tab met de naam 


van de query (in dit geval Queryr) en in het menu SQL-weergave te kiezen. Het SQL- 
statement van deze query luidt: 


SELECT STUDENT.Voornaam, STUDENT Achternaam 
FROM STUDENT: 


Je kunt elk SQL-statement in dit venster invoeren dat je maar wilt gebruiken, zelfs 
als dat statement een andere tabel verwerkt dan STUDENT. Je kunt deze voorziening 
gebruiken om je te helpen de SQL-statements te leren in hoofdstuk 2 en 7. 


Sluit het venster dat de query toont. Access zal je vragen of je de wijzigingen in 
de query wilt opslaan. Klik op Ja en geef de query een duidelijke naam, zoals 
VoorEnAchternaam. 


A7 Formulieren en rapporten maken 


Een formulier geeft je de mogelijkheid om gegevens op een geordende manier in 
een of meer tabellen van een database in te voeren, of om aanwezige gegevens te be- 
kijken en eventueel wijzigen. Een bekend voorbeeld van een formulier vind je in een 
webwinkel. Als je in een webwinkel iets koopt moet je in het algemeen een formu- 


lier invullen met onder andere je adresgegevens. Deze gegevens worden dan via het 
formulier in een database opgeslagen. 


Een rapport geeft op een geordende manier een overzicht van (een deel van) de gege- 
vens in een of meer tabellen van een database. Rapporten en formulieren zijn in de 
eerste plaats bedoeld voor eindgebruikers van de database, die geen kennis hebben 
(en hoeven te hebben) van het ontwerp van de database. 
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Access beschikt over zogeheten wizards, die je stap voor stap leiden door het proces 
van het maken van een formulier of rapport. Ze vormen een goed uitgangspunt om 
de mogelijkheden van formulieren en rapporten in Access 2007 te verkennen. 


Een formulier maken 

De wizard voor het maken van een formulier start je als volgt: 
e _ Klik in de werkbalk op Maken (Create) 

* Klik op de knop Meer formulieren (More Forms) 

* Klik op Wizard Formulier (Form Wizard) 


Een rapport maken 

De wizard voor het maken van een rapport start je als volgt: 
+ _ Klik in de werkbalk op Maken (Create) 

+ Klik op de knop Wizard Rapport (Report Wizard) 


Een voorbeeld van een rapport zie je in Figuur A-12, dat een overzicht geeft van de 
cijfers die door studenten voor verschillende vakken behaald zijn. Merk op dat de ge- 


gevens in dit rapport afkomstig zijn uit drie verschillende tabellen, maar dat dat voor 
de gebruiker van het rapport niet zichtbaar. 


Behaalde cijfers 


ETE 


Ef | Gs) 

Sam Kok j 

Accounting 1 1,5 

Scheikunde 1 1,7 
Marcia Lerik 

Scheikunde 1 7,7 
Louis Holman 

Scheikunde 1 7,1 
Gerda Groen 

Accounting 1 1,9 

Accounting 2 1,5 

Figuur A-12 


In het algemeen verbergen rapporten en formulieren de technische details van de 
database voor de gebruiker. 
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Bijlage B 
De standaard IDEFIX 


IDEFIX (Integrated Definition 1, Extended) is, zoals al eerder werd vermeld, een 
versie van het E-R-model die in 1993 tot een Amerikaanse nationale standaard werd 
benoemd. Deze standaard was gebaseerd op werk dat eerder, in het midden van de 
jaren 1980, was gedaan voor het Amerikaanse leger. IDEFIX is gebaseerd op het E-R- 
model, maar breidt dat model uit met ondersteuning voor het maken van conceptuele 
en interne schema's. IDEF1X is standaard voor relationele database. 

IDEF1X omvat entiteiten, relaties en attributen, maar beperkt de betekenis van die 
termen en kwalificeert ze met een meer specifieke terminologie. IDEF1X omvat daar- 
naast de definitie van het domein, een onderdeel dat niet voorkomt in het uitgebreide 
E-R-model. IDEF1X veranderde ten slotte de grafische symbolen voor E-R. De ruit is ver- 
wijderd en er zijn nieuwe symbolen toegevoegd voor categorieën, evenals een versie 
van generalisatiehiërarchieën en subtypen. Figuur B-1 vat de verschillen samen tussen 
het uitgebreide E-R-model en het model IDEF1X. 
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Term van uitge- Opmerkingen Ì 


bridge E-R-model 


Entiteit 
Attribuut 


1:1- EN 
1:N-relaties 


N:M-relaties 


ID-afhankelijke 
relatie 


Zwakke, maar niet 


ID-afhankelijke 
relatie 


Overeenkomstige 
term van IDEF1X- 
versie van E-R-model 


Entiteit 
Attribuut 


Identiek 
Identiek 


nl 
el 
Identiek 

Een verbindingsrelatie 


is hetzelfde als een 
HEEFT-EEN-relatie 


Relatie 


Niet identificerende 
verbindingsrelatie 


Niet-specifieke relatie 


ldentificerende 
verbindingsrelatie 


Geen 


Supertype entiteit 


Algemene entiteit Een algemene entiteit 
heeft een IS-EEN- 
relatie met een 


categoriecluster 


Subtype entiteit Categorie-entiteit Categorie-entiteiten | 
sluiten elkaar 
tegenzijdig uit in 
hun categoriecluster 


Figuur B-1 De overeenkomst tussen de termen van het uitgebreide E-R-model en de IDEF1X-versie van het 
E-R-model 


B1 IDEF1X-entiteiten 


IDEF1X-entiteiten zijn identiek aan de entiteiten van het uitgebreide E-R-model. Ze 
representeren iets dat de gebruikers willen bijhouden iets waar de gebruikers gege- 
vens over willen bewaren. Entiteiten worden net als bij het uitgebreide E-R-model 
weergegeven met vierkante of afgeronde hoeken, hoewel entiteiten met afgeronde 
hoeken een wat andere betekenis hebben in IDEFiX. Je leest daar meer over in de 
bespreking van relaties. 


B2 IDEF1X-relaties 


Figuur B-2 toont de vier soorten IDEFrX-relaties. De terminologie is weliswaar wat 
onhandig, maar ook zeer specifiek. De vier relaties zijn: 


e Niet identificerende verbindingsrelaties 
e |dentificerende verbindingsrelaties 


e Niet-specifieke relaties 
e Categorierelaties 


Figuur B-2 Soorten IDEF1%-relaties 
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B2.1 Niet identificerende verbindingsrelaties 

Niet identificerende verbindingsrelaties zijn r:1- of r:N-relaties tussen twee niet [D- 
afhankelijke (vandaar niet identificerende) entiteiten. Verbindingsrelaties zijn hetzelf. 
de als de HEEFT-EEN-relaties van het uitgebreide E-R-model. 

Figuur B-3 toont voorbeelden van niet identificerende verbindingsrelaties. Niet 
identificerende verbindingsrelaties worden volgens de standaard weergegeven met 
een stippellijn. Verbindingsrelaties worden in IDEF1X bovendien altijd getekend 
vanaf een parent naar een childentiteit. De parent is in het geval van r:N-relaties de 
entiteit aan de r-kant van de relatie. Bij een r:1-relatie kan elk van de entiteiten als de 
parent worden gezien, maar IDEF1X dwingt je een van die entiteiten te kiezen voor 
deze rol. Zoals je in Figuur B-3 ziet, eindigt de relatielijn in een gevulde cirkel aan de 
kant van de childentiteit in een IDEFrX-relatiediagram. 

De standaardkardinaliteit van een niet identificerende verbindingsrelatie is een- 
op-veel in IDEFrX, met een verplichte parent en een optionele child. Dergelijke rela- 
ties worden weergegeven met een stippellijn met een gevulde cirkel naast de child en 
geen andere notaties. De relatie tussen AFDELING en MEUBILAIR is dus r:N in Fi- 
guur B-3 — een AFDELING hoeft geen MEUBILAIR te hebben en elke MEUBILAIR- 
entiteit moet aan een AFDELING zijn toegekend. 

Er worden extra notaties aan het diagram toegevoegd als de relatiekardinaliteit 
van de standaard verschilt. Een P naast de cirkel geeft aan dat er een of meer childen- 
titeiten vereist zijn (de P staat voor positief, net als bij positief getal). Er wordt een ruit 
naast de parent aan de lijn toegevoegd als de parent optioneel is. De relatie tussen 
AFDELING en WERKNEMER is r:N in Figuur B-3 —een AFDELING moet minstens 
een WERKNEMER hebben en een WERKNEMER hoeft niet aan een AFDELING te 
zijn gerelateerd. 

L:I-relaties worden aangegeven door een notatie naast de cirkel aan de relatielijn 
toe te voegen. Een r geeft aan dat er precies één child nodig is, een Z geeft aan dat er 
nul of een child is toegestaan. Een WERKNEMER is dus met precies een BADGE- 
entiteit en met nul of een COMPUTER-entiteiten verbonden in Figuur B-3. De ruit 


MEUBILAIR 


AFDELING 


AfdNaam H 


BudgetCode 
KantoorNummer |, 


Materiaal 
Datum Gekocht 


1 
I 
| 


P 
Ad 
BADGE WERKNEMER COMPUTER 


UitgaveDatum £ khen 
UitgegevenDoor | 


Figuur B-3 Niet identificerende verbindingsrelaties 


Naam 
Telefoon 
BaanCode 


SchijfCapaciteit|| 
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geeft aan dat een COMPUTER niet aan een WERKNEMER hoeft te zijn gerelateerd. 
Er is geen ruit aan de WERKNEMER-kant van de relatie BADGE: WERKNEMER en 
een BADGE moet dus aan een WERKNEMER zijn gekoppeld. 


B2.2 Identificerende verbindingsrelaties 

Identificerende verbindingsrelaties zijn hetzelfde als [D-afhankelijke relaties in het 
uitgebreide E-R-model. De identifier van de parent maakt altijd deel uit van de iden- 
tifier van de child. Een GEBOUW-entitieit is in Figuur B-4 de parent van een ID- 
afhankelijke relatie met de entiteit KANTOOR. Merk op dat de identifier GEBOUW, 
GebouwNummer deel uitmaakt van de identifier van KANTOOR. De notatie (FK) 
betekent dat het attribuut een externe sleutel (foreign key) is van een andere entiteit 
(hier GEBOUW). Identificerende relaties worden aangegeven met ononderbroken 
lijnen en childentiteiten worden weergegeven met afgeronde hoeken in identifice- 
rende relaties. 

We mogen in dit voorbeeld aannemen dat we de standaardkardinaliteit moeten 
gebruiken, want er staat geen extra notatie naast de gevulde cirkel. Een GEBOUW 
kan dus verbonden zijn met nul, een of veel KANTOORen. Een GEBOUW zou aan 
maximaal één, nul of één of één of meer KANTOOR-entiteiten worden gekoppeld 
als er respectievelijk een r, een Z of een P naast de cirkel zou worden geplaatst. Er 
kan nooit een ruit aan de kant van de parent geplaatst worden in een identificerende 
relatie, want children hebben altijd een parent nodig in een identificerende relatie. 

IDEFrX staat weliswaar zwakke entiteiten toe die niet identificerend zijn, maar 
er is geen speciale notatie voor dergelijke entiteiten. De enige manier waarop kan 
worden gedocumenteerd dat dergelijke entiteiten logisch afhankelijk zijn van hun 
parent is dat de minimumkardinaliteit 1 is voor de parent in een dergelijke relatie. 


GEBOUW KANTOOR 


KantoorNummer 
GebouwNummer (FK) 


GebouwNummer 


Receptietelefoon 
AantalVerdiepingen) 
ParkeerPlaats 


NetPoortNummer 
TelefoonPoortNummer |! 
MaxCapaciteit | 


Figuur B-4 Identificerende verbindingsrelatie 


B2.3 Niet-specifieke relaties 
Een niet specifieke IDEFrX-relatie is gewoon een veel-op-veel relatie. Niet-specifieke 
relaties worden weergegeven met een gevulde cirkel aan beide kanten van een on- 
onderbroken relatielijn, zoals je dat ziet in Figuur B-5. Er kan in IDEF1X geen mini- 
mumkardinaliteit worden ingesteld voor een niet-specifieke relatie. 

IDEFIX behandelt veel-op-veel relaties als een soort achtergebleven stiefkinderen 
van niet identificerende verbindingsrelaties. Dat komt omdat dergelijke relaties niet 
rechtstreeks kunnen worden uitgedrukt in het relationele model. Ze moeten, zoals 
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je in hoofdstuk 5 zult zien, in twee r:N-relaties worden omgezet, voordat ze door een 
relationele database kunnen worden verwerkt. 

Dit is volgens sommige mensen een grote fout in IDEF:X, want dit vermengt 
ideeën van conceptuele schema's met ideeën van interne schema's. Deze mensen 
vinden dat een _N;M-relatie volledig in het conceptuele model zou moeten kunnen 
worden gedocumenteerd, inclusief minimumkardinaliteiten. Wat er later, tijdens 
het ontwerpen van het interne schema, met die relatie gebeurt zou niet van belang 
mogen zijn tijdens het conceptueel ontwerpen. 


WERKNEMER 
VAARDIGHEID 
Naam VaardigheidNaam | 
delsfaan Beschrijving 


BaanCode 


Figuur B-5 Niet-specifieke model met N:M-relatie 


B3 Categorierelaties 


Categorierelaties zijn een speciaal geval van generalisatie/subtyperelaties in het uit- 
gebreide E-R-model. Een categorierelatie is specifiek een relatie tussen een algemene 
entiteit en een andere entiteit die een categorie-entiteit wordt genoemd. Categorie- 
entiteiten worden gegroepeerd in categorieclusters. WERKNEMER is in Figuur 
B-6 bijvoorbeeld een algemene entiteit, PROGRAMMEUR, PQA_INGENIEUR en 
TECH_ SCHRIJVER zijn categorie-entiteiten en de verzameling PROGRAMMEUR, 
PQA-INGENIEUR en TECH_SCHRIJVER vormt de categoriecluster, die wordt aan- 
gegeven met de gevulde cirkel boven twee horizontale lijnen. 

Categorierelaties zijn IS-EEN-relaties. Een programmeur is bijvoorbeeld een 
werknemer. Dat betekent dat de primaire sleutel van de categorie-entiteiten dezelfde 
is als de categoriesleutel van de algemene entiteit. De primaire sleutel van PRO- 
GRAMMEUR, PQA-INGENIEUR en TECH-SCHRIJVER is hier SSN. Categorie-en- 
titeiten worden daarom zonder primaire sleutels weergegeven. 

De entiteiten in een categoriecluster sluiten elkaar tegenzijdig uit in IDEFIX. Een 
WERKNEMER kan in Figuur B-6 een PROGRAMMEUR zijn, een PQA_INGENI- 
EUR of een TECH_SCHRIJVER. Een werknemer kan niet twee of meer van deze 
beroepen hebben. 

Categorieclusters kunnen een discriminator hebben. Dat is een attribuut van 
de algemene entiteit die het type van de WERKNEMER aangeeft. In Figuur B-6 is 
BaanCode de discriminator. Dat betekent dat de waarde van BaanCode kan worden 
gebruikt om te bepalen of een WERKNEMER een PROGRAMMEUR, een PQA_ 
INGENIEUR of een TECH SCHRIJVER is. Er wordt niet in het conceptuele mo- 
del aangegeven op welke manier dat gedaan wordt — we registreren hier alleen dat 
het kan worden gedaan. Sommige categorieclusters hebben geen discriminator — er 
wordt opengelaten hoe de categorie-entiteit wordt bepaald. 
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Er zijn twee soorten categorieclusters: volledige en onvolledige. Een volledige cate- 
goriecluster toont elke mogelijke soort categorie voor de cluster. Volledige categorie 
clusters worden aangegeven met twee horizontale lijnen met een ruimte daartussen. 
De categoriecluster in Figuur B-6 is volledig. Dat betekent dat alle categorieën van 
WERKNEMER worden getoond — er is geen ontbrekende categorie. Elke WERKNE- 
MER kan dus gecategoriseerd worden als zijnde een PROGRAMMEUR, een PAQ_ 
INGENIEUR of een TECH_SCHRIJVER. 


Opmerking 

Je zult nu misschien denken: ‘wacht eens even, er zijn natuurlijk ook nog andere soorten 
werknemers. Waar zijn bijvoorbeeld de boekhouders gebleven?’ Het punt is dat er volgens dit model 
geen andere soorten werknemers zijn. Dit model zal misschien alleen gebruikt worden in een 
softwareontwikkelingsgroep waarin geen andere soorten werknemers voorkomen. Of het kan zijn dat 


het model niet klopt. Dat maakt niet uit. Er zijn hoe dan ook volgens dit model geen andere soorten 
werknemers. 


WERKNEMER 


Naam 
Telefoon 
BaanCode 


Titel 
Taal 


Figuur B-6 Categorierelatie 


Alle categorie-entiteiten zijn voor hun bestaan afhankelijk van de algemene cate- 
gorie. Dat betekent dat de minimumkardinaliteit van de categorie-entiteit naar de 
algemene entiteit altijd één is. Deze kardinaliteit wordt daarom niet in het diagram 
weergegeven. 

De kardinaliteiten van de relaties tussen de algemene entiteit en de categorie- 
entiteiten zijn altijd nul of één volgens de standaard IDEFIX. De Z op de lijn tussen 
de algemene entiteit en het clustersymbool geeft aan dat een WERKNEMER al dan 
niet een van de categorie-entiteiten kan hebben. De Z op de lijnen naar de categorie- 
entiteiten tonen dat de algemene entiteit al dan niet een van deze typen kan zijn. 

Veel mensen vinden het raadselachtig of zelfs verkeerd dat de Z-notatie op deze 
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manier wordt gebruikt. De categorieën in een cluster sluiten elkaar, zoals al eerder 
werd vermeld, tegenzijdig uit. Heeft een entiteit een relatie met een van de categorie- 
entiteiten, dan moet de kardinaliteit van de relatie met de andere entiteiten in die 
cluster dus nul zijn. De Z op de lijn tussen de algemene entiteit en het clustersym- 
bool geeft bovendien aan dat een algemene entiteit al dan niet een categorie-entiteit 
kan hebben. De Z moet bij volledige clusters in sommige gevallen 1 zijn. Dat geeft 
aan dat de algemene entiteit een relatie moet hebben met een categorie-entiteit. Het 
is met het model IDEFrX niet mogelijk 1 op te geven voor dit geval. 

Figuur B-7 toont een tweede categoriecluster die bestaat uit de categorie-entitei- 
ten MANAGER en STAF. Deze cluster is onvolledig, wat wordt aangegeven door de 
categorieclustercirkel boven een enkele lijn te plaatsen. Er is geen ruimte tussen ho- 
rizontale lijnen. Dat betekent dat er minstens een categorie ontbreekt. Een werkne- 
mer kan bijvoorbeeld een PART_TIME-werknemer zijn. De kardinaliteiten worden 
ook hier weer allemaal aangegeven als Z. 

We hebben al gezegd dat categorie-entiteiten elkaar tegenzijdig uitsluiten binnen 
een categoriecluster. Dat betekent echter niet dat een entiteit geen relatie kan hebben 
met twee of meer categorie-entiteiten in verschillende clusters. Een WERKNEMER 
kan dus, zoals je in Figuur B-7 ziet, een MANAGER en ook een PROGRAMMEUR 
zijn. Een WERKNEMER kan echter niet zowel een MANAGER als STAF zijn. 

Je ziet dat het model IDEFrX structuur toevoegt aan de generalisatie/subtypere- 
laties van het uitgebreide E-R-model. Het model IDEF1X definieert deze concepten 
nader en geeft deze daardoor meer betekenis en maakt ze nuttiger. 


WERKNEMER 


Naam 
Telefoon 
BaanCode 


(©) BaanCode 


Z ZA 7e Z 
MANAGER STAF PROGRAMMEUR PQA_INGENIEUR TECH_SCHRIJVER 


JarenErvaring 
Taal 


Besturingssysteem | 
Zj 


Figuur B-7 Volledige en onvolledige categorieclusters 


B4 Domeinen 


IDEFrX introduceert het concept van domeinen in het uitgebreide E-R-model. Een 
domein is een benoemde verzameling waarden, die een attribuut kan hebben. Een 
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domein kan uit een lijst met specifieke waarden bestaan, of kan op een meer alge- 
mene manier worden gedefinieerd, bijvoorbeeld als een verzameling strings met 
een maximale lengte van so. Een universiteit kan bijvoorbeeld een domein hebben 
met de naam AFDELING_NAMEN, dat de namen omvat van alle officiële afdelingen 
van de universiteit. Het domein zou gedefinieerd worden door deze lijst op te som- 
men: {‘Boekhouding’, ‘Biologie’, ‘Scheikunde’, ‘Informatica’, ‘Informatiesystemen!, 
‘Management’, ‘Natuurkunde'}. Het domein STUDENT _NAMEN zou op de tweede 
manier kunnen worden gedefinieerd, als een willekeurige string met een lengte klei- 
ner dan 75. 


B4.1 Domeinen zorgen voor minder onduidelijkheid 

Domeinen zijn belangrijk en nuttig. Merk bijvoorbeeld op dat PROGRAMMEUR 
en TECH_ SCHRIJVER beide een attribuut met de naam Taal hebben in Figuur B-7. 
Deze namen zouden zonder domeinen dubbelzinnig zijn. Refereren ze aan hetzelf- 
de ding of niet? Het kan zijn dat Taal een computertaal is voor PROGRAMMEUR en 
een menselijke taal voor TECH_SCHRIJVER. Maar ze kunnen ook beide een com- 
putertaal zijn. Deze dubbelzinnigheid kan opgelost worden door het domein op te 
geven waar elk van deze attributen op is gebaseerd. 

We kunnen het domein COMPUTER TAAL definiëren als de lijst {'C#'‚ ‘C++’, 
‘Java’, ‘VisualBasic', ‘VisualBasic.NET’} en het domein MENSELIJKE_TAAL als 
{“ Canadees Frans’, ‘Frans Frans’, ‘Spaans’, ‘Brits Engels’, ‘Amerikaans Engels'}. 
De attributen zullen nooit meer dubbelzinnig zijn als we nu zeggen dat Taal van 
PROGRAMMEUR is gebaseerd op het domein COMPUTER_TAAL en dat Taal van 
TECH_SCHRIJVER is gebaseerd op het domein MENSELIJKE_ TAAL. 

Benoemde domeinen maken bovendien attributen ondubbelzinnig die waarden 
hebben die soortgelijk lijken, maar niet hetzelfde zijn. Stel dat stafwerknemers 30 
vakantiedagen kunnen opbouwen in Figuur B-7. Stel verder dat er wordt aangeno- 
men dat werknemers nooit meer dan 30 jaar werken. De attributen STAF.Vakan- 
tieDagen, PQA_INGENIEUR JarenErvaring en TECH_SCHRIJVER.JarenErvaring 
zullen in dat geval allemaal waarden hebben tussen o en 30. (We identificeren attri- 
buten in deze notatie door er een punt achter te plaatsen, gevolgd door de domein- 
naam.) Zouden er geen domeinen zijn opgegeven, dan zouden we niet kunnen zien 
of deze waarden naar hetzelfde ding verwijzen of niet. 

Stel dat we een domein VAKANTIE _DAGEN definiëren als integers van o tot 
en met 30 en een tweede domein ERVARING als integers van o tot en met 30. We 
kunnen nu opgeven dat het attribuut STAF.VakantieDagen is gebaseerd op het do- 
mein VAKANTIE DAGEN en dat de attributen PQA_INGENIEUR.JarenErvaring 
en TECH_SCHRIJVER.JarenErvaring zijn gebaseerd op het domein ERVARING. 


B4.2 Domeinen hebben een praktisch nut 

Domeinen zorgen niet alleen voor minder onduidelijkheid, maar ze hebben ook 
een praktisch nut. Stel dat we een attribuut met de naam CampusAdres hebben in 
een model van een universiteitsdatabase en dat dit attribuut door veel verschillende 
entiteiten wordt gebruikt, zoals door STUDENT, PROFESSOR, AFDELING, LAB 
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enzovoort. Stel verder dat we al deze CampusAdres-attributen op hetzelfde domein 
baseren en dat we dit domein met de naam CAMPUS_ADRES definiëren als alle 
waarden met het patroon BBB-NNN, waarbij BBB een lijst van gebouwencodes is en 
NNN een lijst van kamernummers is. Alle attributen van het model zullen deze de- 
finitie erven als we het domein op deze manier definiëren. E 

Stel nu dat we tijdens met opzetten van ons model merken dat sommige kamer- | 
nummers vier cijfers hebben. Zou er geen domeindefinitie zijn, dan zouden we alle 
attributen in het domein moeten opzoeken die een campusadres gebruiken en zou- 
den we het kamernummer van al deze attributen in NNNN moeten veranderen. Zijn 
er domeinen, dan kunnen we simpelweg de definitie van het domein veranderen en 
alle op dat domein gebaseerde attributen zullen deze wijziging erven. Daar is niet al- 
leen minder werk voor nodig, maar het elimineert ook fouten die moeilijk te vinden 
en nog moeilijker te verhelpen zijn. 

Een ander praktisch nut van domeinen is voor het bepalen of twee attributen met 
verschillende namen misschien naar hetzelfde ding verwijzen. Een entiteit AFDE- 
LING zal bijvoorbeeld misschien een attribuut met de naam BudgetCode hebben, 
terwijl een tweede entiteit PROJECT een attribuut met de naam OnkostenCategorie 
heeft. Worden er domeinen gebruikt, dan kunnen we gemakkelijk controleren of 
deze beide attributen op hetzelfde domein zijn gebaseerd. Het zou zonder domeinen 
moeilijk zijn dat te weten te komen. Waarden van attributen kunnen verschillende 
betekenissen hebben, ook al lijken ze sterk op elkaar. 


B4.3 Basisdomeinen en getypeerde domeinen 

IDEFrX definieert twee soorten domeinen. Een basisdomein is een domein met 
een datatype en misschien een waardelijst of een gedefinieerd bereik. De standaard- 
datatypen zijn Character, Numeric en Boolean. De specificatie staat het gebruikers 


Boekhouding, Biologie, Chemie, 


Domein Computerwetenschappen, 
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Figuur B-8 Voorbeeld van een domeinhiërarchie 
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toe extra datatypen te definiëren, zoals Datum, Tijd, Monetair enzovoort. Een waarde- 
lijst is een verzameling waarden, zoals die voor het domein COMPUTER_ TAAL, en 
een bereikdefinitie lijkt op wat we voor het domein ERVARING hebben beschreven. 

Een getypeerd domein is een subset van een basisdomein, of een subset van een 
ander typedomein. Figuur B-8 illustreert typedomeinen gebaseerd op het domein 


AFDELING_NAMEN. Typedomeinen maken het mogelijk meer specifieke domein- 
hiërarchieën te definiëren. 


Herhalingsvragen 


B-1r Waarom is IDEFrX belangrijk? 

B-2 Benoem de vier typen IDEFrX-relaties. 

B-3 Wat is een niet identificerende verbindingsrelatie? Wat is het verband tussen 
deze relaties en het uitgebreide E-R-model dat is beschreven in hoofdstuk 5? 

B-4 Wat is een identificerende verbindingsrelatie? Wat is het verband tussen deze 
relaties en het uitgebreide E-R-model dat is beschreven in hoofdstuk 5? 

B-5 Wat is een niet specifieke relatie? Wat is het verband tussen deze relaties en het 
uitgebreide E-R-model dat is beschreven in hoofdstuk 5? 


B-6 Wat zijn de verschillen tussen categorierelaties en supertype/subtype relaties in 
het uitgebreide E-R-model uit hoofdstuk 5? 


B-7 Wat zijn de belangrijkste voordelen van domeinmodellering? 
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Bijlage C 
Entiteit-relatiediagrammen 
in UML 


De Unified Modeling Language (UML) is een verzameling structuren en technieken 
voor het modelleren en ontwerpen van objectgeoriënteerde programma's (OOP) en 
applicaties. UML is vooral bekend geworden dankzij de Object Management Group, 
een organisatie die al sinds de jaren 1980 OOP-modellen, -technieken en -standaarden 
ontwikkelt. Er wordt ook steeds meer gebruik van gemaakt door mensen die met OOP 
werken. UML is de basis van de objectgeoriënteerde ontwerptools Rational Systems. 
UML is een methodologie voor het ontwikkelen van applicaties en is daarom een 
onderwerp voor een cursus over systeemontwikkeling — en is hier eigenlijk van weinig 


belang voor ons. Je zult echter misschien relatiediagrammen in de stijl van UML tegen- 
komen en je moet daarom bekend zijn met deze stijl. 
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C1 UML-entiteiten en -relaties 


Figuur C-1 toont de UML-representatie van een r:r-, een r:N- en een N:M HEEFT 
EEN-relatie. Elke entiteit wordt gerepresenteerd door een entiteitklasse, die wordt 
weergegeven als een in drie blokken verdeelde rechthoek. Het bovenste blok toont de 
naam van de entiteit en andere gegevens die we nog zullen bespreken. Het tweede 
blok bevat een lijst met de namen van de attributen van de entiteit. Het derde blok 
documenteert constraints en noemt methoden (programmaprocedures) die bij de 
entiteit horen. 

Relaties worden weergegeven als een lijn tussen twee entiteiten. Kardinaliteiten 
worden gerepresenteerd in de notatie x.y, waarbij x het vereiste minimum is en y het 
toegestane maximum. o…1 betekent dus dat er geen entiteit vereist is en dat er maxi- 
maal r is toegestaan. Een asterisk representeert een onbeperkt aantal. 1. 


WERKNEMER AUTO 
WerknemerlD AUTO TOEKENNING KentekenNummer 
Naam 04 1 ChassisNummer 
Titel = —{ Merk 
Telefoon Model 
VaardigheidCode Jaar 
Constraints en methoden Constraints en methoden 
worden hier genoemd 


worden hier genoemd 


(a) 


STUDENTENHUIS 


STUDENT 


STUDENTENHUIS- 


Naam StudentNummer 
CampusAdres 04 BEWONER 41.0 StudentNaam 
Capaciteit = —j Telefoon 
HuisTelefoon Klas 


ToegekendeKamer 


Constraints en methoden 
worden hier genoemd 


Constraints en methoden 
worden hier genoemd 


(b) 


STUDENT 
STUDENT-CLUB 


StudentNummer ClubNummer 
StudentNaam 0. 0. BudgetCode 
Telefoon = ——j Beschrijving 


Klas President 
ToegekendeKamer PresidentTelefoon 


Constraints en methoden Constraints en methoden 
worden hier genoemd worden hier genoemd 


(c) 


Figuur C-1 (a) UML-representatie van een 1:1-relatie, (b) UML-representatie van een 1:N-relatie en (c) UML 
representatie van een N:M-relatie 
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C1.1 _Representeren van zwakke entiteiten 

Figuur C-2 toont de UML-representatie van zwakke entiteiten. Er wordt een gevulde 
ruit op de lijn geplaatst naar de parent van de zwakke entiteit (de entiteit waar de 
zwakke entiteit van afhankelijk is). RECEPT is in Figuur C-2 de zwakke entiteit en 
PATIENT is de parententiteit. Zwakke entiteiten hebben altijd een parent en de kar- 
dinaliteit aan hun kant van de zwakke relatie is dus altijd 1.1. De kardinaliteit van de 
parententiteit wordt daarom simpelweg genoteerd als 1. 

Figuur C-2(a) toont een zwakke entiteit die niet [D-afhankelijk is. Deze wordt aan- 
gegeven met de uitdrukking <niet identificerend> bij de relatie PATIËNT-RECEPT. 
Figuur C-2(b) toont een zwakke entiteit die ID-afhankelijk is. Deze worden aangege- 
ven met het label <identificerend>. 


C1.2 _Subtypen representeren 

Je ziet in Figuur C-3 hoe UML subtypen representeert. De subtypen INDIVIDU, 
PARTNERSCHAP en BEDRIJF van CLIËNT zijn hier toegestaan. Een gegeven 
CLIENT kan volgens deze figuur een, twee of drie van deze subtypen zijn. Dat klopt 
niet voor deze situatie: een CLIËNT hoort maar één van deze typen te zijn. De hui- 
dige versie van UML biedt geen manier voor het documenteren van exclusiviteit. 
Er kan echter wel een dergelijke notatie aan een UML-diagram worden toegevoegd. 


If PATIENT RECEPT 
N PATIENT-RECEPT Dat 

aam <niet identificerend> SU 
Telefoon \ 0.” ReceptlD 
VerzekeringMaatschappij (@- —| Arts 


VerzekeringNummer Medicijn 


Aantal 


zi 


Identifier: Naam ldentifier: ReceptlD 


Methoden Methoden 
(a) 

PROJECT TOEKENNING 
ProjectNaam er en TaakNaam 
BeginDatum bete and TaakBegin 

eg 1 0. 
EindDatum SchattingUren 
BudgetCode 


WerkelijkeUren 
WerknemerNaam 


Identifier: TaakNaam 
Methoden 
(b) 


Figuur C2 UML-representatie van zwakke entiteiten: (a) niet ID-afhankelijke zwakke entiteit en (b) ID-afhan- 
kelijke zwakke entiteit 


ldentifier: ProjectNaam 
Methoden 
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CLIËNT 


CliëntNummer 
CliëntNaam 
OpenstaandBedrag 


Identifier: CliëntINummer 
Methoden 


CliëntType 


PARTNERSCHAP 


NaamSeniorPartner 
Adres 
BelastingNummer 


INDIVIDU 


Adres 
SoFiNummer 


BEDRIJF 


ContactPersoon 
Telefoon 


BelastingNummer 


Methoden 


Methoden Methoden 


Figuur C-3 UML-weergave van subtypen 


Herhalingsvragen 


C-r Waarom is UML belangrijk? Waarom is het van belang voor databaseontwerpers? 
C-2 Toon een r:r-relatie in UML-formaat. 

C-3 Toon een r:N-relatie in UML-formaat. 

C-4 Toon een N:M-relatie in UML-formaat. 

C-5 Leg uit hoe UML-documenten kardinaliteit verminderen. 


C-6 Toon identificerendeen nietindentificerende zwakke entiteiten in UM L-formaat. 
C-7 Toon subtypen in UML-formaat. 


C.8 Wat zijn klasseattributen? Hoe worden ze gedocumenteerd in UML? 


C-g Hoe worden klasseattributen weergegeven in het uitgebreide E-R-model uit 
hoofdstuk 5? 


C-ro Geef een voorbeeld van een constraint op een entiteit in een UML-diagram. 
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Bijlage D 
Datastructuren voor 
databaseverwerking 


Alle besturingssystemen bieden een aantal functies voor het beheren van gegevens. 
Deze functies zijn meestal echter ontoereikend voor de speciale behoeften van een 
DBMS. DBMS-producten zetten daarom speciale datastructuren op en onderhouden 
deze, met het doel de verwerkingsnelheid te verbeteren. Deze datastructuren zijn het 
onderwerp van deze bijlage. 

We beginnen met een bespreking van de zogenaamde flat files en enkele van 
de problemen die kunnen optreden als zulke bestanden in andere volgordes moeten 
worden verwerkt. Vervolgens behandelen we drie speciale datastructuren: sequentiële 
lijsten, linked lists en indexen (geïnverteerde lijsten). Daarna laten we zien hoe drie 
speciale structuren — boomstructuren, enkelvoudige netwerken en complexe netwer- 
ken -— met behulp van diverse datastructuren kunnen worden gerepresenteerd. Ten 
slotte bespreken we de representatie en verwerking van meervoudige sleutels. 
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Voor de gebruikers van de meeste DBMS-producten is een grondige kennis van 
datastructuren niet strikt noodzakelijk, maar deze achtergrondinformatie wel van 
belang voor databasebeheerders en systeemprogrammeurs. Kennis van datastruc- 


turen kan ook van pas komen bij het beoordelen en vergelijken van verschillende 
databaseproducten. 


D1 Flat files 


Een flat file (of plat bestand) is een bestand zonder herhaalde gegevensgroepen. In 
Figuur D.1(a) is een flat file afgebeeld en in Figuur D-1(b) is een bestand gerepre- 
senteerd dat niet flat is omdat het veld Artikel kan worden herhaald. Een flat file kan 
worden opgeslagen in elke willekeurige standaardbestandsorganisatie zoals sequen- 
tieel, index-sequentieel of direct. Flat files worden al jaren gebruikt in commerciële 
applicaties. Ze worden gewoonlijk in een van tevoren opgegeven volgorde verwerkt, 
bijvoorbeeld in oplopende volgorde van een sleutelveld. 


Inschrijvingsrecord 


Studentnummer Vaknummer Semester | 


Factuurrecord 


Factuurnummer | Artikel(en) 


Voorbeeldgegevens 


Voorbeeldgegevens 


(b) 


Figuur D-1 Voorbeelden van: (a) een flat file en (b) een factuurrecord die geen flat file is 


Student- _Vak- Student- _Vak- 
nummer nummer Semester nummer nummer Semester 


(b) 


Figuur D-2 Inschrijvingsgegevens opgeslagen als sequentiële lijsten: (a) gesorteerd op Studentnummer en (b) 
gesorteerd op Vaknummer 


D1.1 Flat files verwerken in verschillende volgordes 
Soms willen gebruikers flat files verwerken op een manier die niet rechtstreeks 
wordt ondersteund door de gebruikte organisatie van bestanden. Als men aan de 
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hand van de INSCHRIJVING-records in Figuur D-t(a) een overzicht per student 
wil maken, moeten de gegevens in volgorde van het Studentnummer worden door- 
lopen. Maar om lesroosters te produceren, moeten de records in volgorde van Vak- 
nummer worden verwerkt. De records kunnen fysiek natuurlijk maar op één manier 
worden opgeslagen, dus op Studentnummer of op Vaknummer, maar niet op beide 
tegelijk. De gebruikelijke oplossing voor dit probleem is de records eerst te sorteren 
op Studentnummer, de overzichten per student te genereren, de records vervolgens 
op Vaknummer te sorteren en dan de lesroosters te produceren. 

Voor bepaalde applicaties, zoals een batchsysteem, is dit een goede, zij het be- 
werkelijke, oplossing. Maar wat moeten we doen als beide volgordes tegelijk moe- 
ten bestaan, omdat twee gebruikers op hetzelfde moment een andere view op de 
INSCHRIJVING-records willen zien? 

Een mogelijke oplossing is het maken van twee kopieën van het INSCHRIJVING- 
bestand, de ene kopie gesorteerd op Studentnummer en de andere op Vaknummer 
(zie Figuur D-2). Omdat de gegevens sequentieel worden verwerkt, noemt men een 
dergelijke datastructuur ook wel een sequentiële lijst. Sequentiële lijsten kunnen 
eenvoudig worden opgeslagen als sequentiële bestanden, maar door DBMS-produc- 
ten wordt dit eigenlijk nooit gedaan, omdat het sequentieel uitlezen van een bestand 
een traag proces is. Bovendien kunnen sequentiële bestanden niet in het midden 
worden gewijzigd zonder het hele bestand opnieuw te schrijven. Het onderhouden 
van diverse volgordes door verscheidene kopieën van dezelfde sequentiële lijst bij te 
houden is bovendien niet erg effectief, omdat dit tot problemen met de gegevens- 
integriteit kan leiden. Gelukkig bestaan er andere datastructuren waarmee we re- 
cords in verschillende volgordes kunnen verwerken zonder dat er gegevens hoeven 
te worden gedupliceerd. Twee van deze datastructuren zijn linked lists en indexen. 


D1.2 Een opmerking over recordadressering 

Meestal maakt het DBMS grote fysieke records of blokken in direct toegankelijke 
bestanden. Deze records worden gebruikt als opslagruimte voor logische records. 
Meestal zijn er veel logische records per fysieke record. Wij gaan ervan uit dat elke 
fysieke record wordt geadresseerd door zijn relatieve recordnummer (RRN). Een lo- 
gische record kan bijvoorbeeld worden toegewezen aan het fysieke recordnummer 7 
of 77 of ro.ooo. Het relatieve recordnummer is dus het fysieke adres van de logische 
record. Als er meer dan één logische record per fysieke record wordt opgeslagen, 
moet uit het adres ook blijken waar de logische record zich bevindt in de fysieke re- 
cord. Het complete adres van een logische record bestaat dan bijvoorbeeld uit rela- 
tief recordnummer 77, bytelocatie roo. Dit betekent dat de logische record begint bij 
byte roo van blok 77. 

Om de illustraties in dit boek eenvoudig te kunnen houden, nemen we in het ver- 
volg aan dat er slechts één logische record per fysieke record wordt opgeslagen. We 
hoeven dan geen bytelocaties per fysieke record aan te geven. Dit is weliswaar niet 
realistisch, maar vereenvoudigt onze bespreking van de belangrijke punten. 
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D1.3 De volgorde bepalen met linked lists 

Linked lists (linked lists) kunnen worden gebruikt om records in een logische volg- 
orde op te slaan die niet per se gelijk hoeft te zijn aan de fysieke volgorde. Aan elke 
datarecord voegen we een veld, een linkveld, toe met daarin het adres (in onze voor- 
beelden het relatieve recordnummer) van de volgende record in de logische volgorde. 
In Figuur D-3 zijn de INSCHRIJVING-records uitgebreid met een linkveld — in deze 
lijst staan de records in volgorde van Studentnummer. Merk op dat het linkveld voor 
het hoogste Studentnummer in de lijst de waarde o heeft. 

Figuur D-4 toont INSCHRIJVING-records met twee linked lists: in de ene lijst 
staan de gegevens op volgorde van Studentnummer en in de andere lijst staan ze op 
volgorde van Vaknummer. Voor elke lijst is een linkveld aan de records toegevoegd. 

Bij het invoegen en verwijderen van records hebben linked lists een groot voor- 
deel ten opzichte van sequentiële lijsten. Als we bijvoorbeeld de INSCHRIJVING 
record voor Student 200 en Vak 45 willen invoegen, moeten beide lijsten in Figuur 
D-2 worden herschreven. In de linked lists in Figuur D-4 kan de nieuwe record ech- 
ter worden toegevoegd aan het fysieke einde van de lijst en hoeven alleen de waarden 
van twee linkvelden te worden gewijzigd om de nieuwe record in de juiste volgorde 
te plaatsen. In Figuur D-5 zijn deze aanpassingen uitgevoerd. 


Relatieve 
record- _Student- Vak- 

nummer _nummer nummer Semester Link 
1 


BWN 


Begin van lijst = 2 


Figuur D-3 INSCHRIJVING-gegevens in volgorde van Studentnummer met gebruik van een linked list 


Relatieve 

record- _Student- Vak- Link Link 

nummer __ nummer nummer Semester student vak 
1 2000.2 


DAO N 


Beoin van ist met TEGENS 2 
Begin van lijst met vakken = 6 


Figuur D-4 INSCHRIJVING-gegevens in volgorde van Studentnummer en Vaknummer met behulp van twee 
linked lists 
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Relatieve 
record- _ Student- Vak- Link Link 
nummer _ nummer nummer Semester student _ vak 


1 200 70 [ 20002 
100 30 


NOA EW N 


Begin van lijst met studenten = 2 
Begin van lijst met vakken = 6 


Figuur D-S5 INSCHRIJVING-gegevens na het invoegen van een nieuwe record (in twee volgordes met behulp 
van linked lists) 


Relatieve 
record- _ Student- Vak- Link Link 
number nummer nummer Semester student vak 
1 200 ’ 70 
2 100 30 
3 300 | 20 
4 200 30 
5 |_300 70 
6 100 20 
7 


Begin van lijst met studenten = 2 
Begin van lijst met vakken = 6 


Figuur D-6 INSCHRIJVING-gegevens na het verwijderen van Student 200, Vak 30 (in twee volgordes met be- 
hulp van linked lists) 


Als er een record uit een sequentiële lijst wordt verwijderd, ontstaat een gat in de 
lijst. In een linked list kan een record worden verwijderd door de linkwaarden, of 
pointervelden, aan te passen. In Figuur D-6 is de INSCHRIJVING-record voor Stu- 
dent 200 met Vak 30 logisch gezien verwijderd. Er wijst geen andere record meer 
naar het adres ervan — de record is dus uit de keten verwijderd, maar blijft fysiek 
bestaan. 

Er bestaan veel varianten van linked lists. We kunnen de lijst bijvoorbeeld tot een 
circulaire lijst of ring maken door de link van de laatste record om te zetten van nul in 
het adres van de eerste record in de lijst. We kunnen elk willekeurig item in de lijst 
dan vanaf elk ander item in die lijst bereiken. In Figuur D-7(a) is een circulaire lijst 
afgebeeld voor de volgorde op Studentnummer. Een double linked list heeft links in 
beide richtingen. In Figuur D-7(b) is een double linked list gemaakt voor de student- 
nummers, die nu zowel in oplopende als in afnemende volgorde kunnen worden 
doorgewerkt. 

Records die met behulp van linked lists zijn gerangschikt, kunnen niet in een 
sequentieel bestand worden opgeslagen, omdat we de linkwaarden alleen kunnen 
gebruiken als er een of andere vorm van directe toegang is. We hebben dus een 
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index-sequentiële of een directe bestandsorganisatie nodig voor het verwerken van 
linked lists. 


D1.4 De volgorde bepalen met indexen 

Een logische recordvolgorde kan ook worden bijgehouden met indexen, die ook wel 
geïnverteerde lijsten worden genoemd. Een index is gewoon een tabel die een verband 
legt tussen recordadressen en veldwaarden. In Figuur D-8(a) zijn de INSCHRIJ- 
VING-records in een willekeurige volgorde opgeslagen en in Figuur D-8(b) is een 
index op Studentnummer opgenomen. In deze index zijn de Studentnummers op 
volgorde gerangschikt, waarbij elk item in de lijst naar een overeenkomende record 
in de originele gegevens verwijst. 

Je ziet dat de index niets meer is dan een gesorteerde lijst met Studentnummers. 
Als we de Studentnummers in INSCHRIJVING willen doorwerken, hoeven we al- 
leen maar de index sequentieel door te werken en de bijbehorende records, die wor- 
den aangegeven door de pointers, in INSCHRIJVING te lezen. In Figuur D-8(c) is 


een andere index voor INSCHRIJVING afgebeeld. Deze houdt de volgorde van Vak- 
nummer bij. 


Relatieve 
record- _Student- Vak- 
nummer __ nummer nummer Semester Link 


1 
2 too | 30 | 20011 | 6 | 
3 
4 
5 2000.2 
Begin van lijst = 2 
(a) 
Relatieve 
record- _Student- Vak- Oplopende Aflopende 
nummer __nummer nummer Semester Link Link 


í 


DR WN 


Begin van oplopende lijst = 2 
Begin van aflopende lijst = 5 


(b) 


Figuur D-7 INSCHRIJVING-gegevens gesorteerd op Studentnummer met behulp van: (a) een circulaire en (b) 
een double linked list 
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Relatieve Relatieve Relatieve 
record- _Student- Vak- Student- record- Vak- _record- 
nummer _nummer nummer Semester nummer number nummer nummer 


1 


100 wim 
_100 | 6 | 
200 
EO En 
ee te 
_300 | 5 | 


ans WN 


(b) (c) 


Figuur D-8 EE met bijbehorende indexen: (a) INSCHRIJVING-gegevens, (b) index op 
Studentnummer en (c) index op Vaknummer 


Een index kan alleen worden gebruikt als de te sorteren gegevens (hier INSCHRIJ- 
VING) zijn opgeslagen in een index-sequentieel of een direct bestand. De indexen 
kunnen in elk bestandstype zijn opgeslagen, maar in de praktijk bewaren bijna alle 
DBMS-producten de gegevens en de indexen in directe bestanden. 

Er is een belangrijk verschil tussen linked lists en indexen. In een linked list wor- 
den de pointers samen met de gegevens opgeslagen. Elke record bevat een linkveld 
met een pointer naar het adres van de volgende record. Maar in een index worden 
de pointers in indexen bewaard, dus gescheiden van de gegevens. De datarecords 


bevatten zelf dus geen pointers. Beide technieken worden door commerciële DBMS- 
producten toegepast. 


D1.5 B-trees 


Een speciale toepassing van het concept van een index of een geïnverteerde lijst is 
de zogenaamde B-tree. Een B-tree is een uit meer niveaus bestaande index waarmee 
sequentiële en directe verwerking van datarecords mogelijk is. Vanwege de wijze 
waarop de indexen zijn gestructureerd, wordt ook de efficiëntie van de verwerking 
vergroot. 

Een B-tree is een index die uit twee onderdelen bestaat: een sequenceset en een 
indexset. (Deze begrippen worden gehanteerd in de documentatie van IBM over 
VSAM-bestandsorganisaties, maar je kunt ook andere synonieme begrippen tegen- 
komen.) De sequenceset is een index waarin voor elke record in het bestand een waar- 
de is opgenomen. Deze index is meestal gesorteerd op de waarde van de primaire 
sleutel. De sequenceset kan de datarecords bevatten (wat in SQL Server een geclus- 
terde index wordt genoemd), of deze kan een pointer naar de datarecords bevatten 
(wat in SQL Server een niet geclusterde index wordt genoemd). 

De indexset is een hiërarchische index voor de sequenceset die wordt gebruikt om 
snel toegang te krijgen tot de sequenceset. 

In Figuur D-g is een voorbeeld van een B-tree afgebeeld en in Figuur D-1o staat 
een instantie van deze structuur. Je ziet dat de onderste rij in Figuur D-g, de se- 
quenceset, gewoon een index is. Deze index bevat een waarde voor elke record in 
het bestand (kortheidshalve zijn de datarecords en bijbehorende adressen weggela- 
ten). Merk verder op dat de gegevens van de sequenceset in groepjes van drie zijn 
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gerangschikt. De gegevens in elke groep staan fysiek op volgorde en elke groep is 
verbonden met de volgende via een linked list (zie Figuur D-1o). 

Bekijk de indexset in Figuur D-g. Het bovenste element bevat twee waarden: 45 
en 77. Als we de meest linkse link (naar RRN2) volgen, kunnen we alle records bena- 
deren waarvan de sleutelveldwaarden kleiner dan of gelijk zijn aan 45. Door de mid- 
delste pointer (naar RRN3) te volgen, krijgen we toegang tot alle records waarvan de 
sleutelveldwaarden groter dan 45 zijn, maar kleiner dan of gelijk aan 77. En door de 
meest rechtse pointer (naar RRN4) te volgen, komen we terecht bij alle records waar- 
van de sleutelveldwaarden groter zijn dan 77. 

Op het volgende niveau staan weer twee waarden en drie pointers per indexele- 
ment. Elke keer dat we een niveau afzakken, komen we dichter in de buurt van een 
bepaalde record. Als we bijvoorbeeld het pad volgen van de meest linkse pointer van 
het bovenste element naar de rechterpointer van het volgende element, komen we 
terecht bij alle records met een sleutelveldwaarde die groter is dan 27 en kleiner dan 
of gelijk is aan 45. We hebben op het eerste niveau alle elementen geëlimineerd die 
groter zijn dan 45. 

B-trees zijn per definitie evenwichtig (of balanced — vandaar de B in B-tree). Daar- 
mee bedoelen we dat alle datarecords steeds op dezelfde afstand van het bovenste 
element in de indexset staan. Dit aspect van B-trees zorgt ervoor dat deze indexen 
zeer efficiënt kunnen worden doorzocht, maar voor het invoegen en verwijderen van 

records zijn wel ingewikkelder algoritmen nodig dan voor gewone boomstructuren 
(die onevenwichtig kunnen zijn). Het kan namelijk zijn dat verscheidene indexgege- 
vens moeten worden aangepast als records worden toegevoegd of verwijderd om alle 
records op dezelfde afstand van het bovenste indexelement te houden. 


D1.6 Samenvatting van datastructuren 

In Figuur D-rr is een overzicht te zien van de technieken voor het onderhouden van 
op volgorde gerangschikte flat files. Er zijn drie ondersteunende datastructuren mo- 
gelijk. Men kan sequentiële lijsten gebruiken, maar in dat geval moeten de gegevens 
worden gedupliceerd om verschillende volgordes te kunnen handhaven. Omdat se- 
quentiële lijsten niet in databaseverwerking worden toegepast, gaan we er verder 
niet op in. Linked lists en indexen kunnen beide worden gebruikt zonder gegevens- 
duplicatie. B-trees zijn speciale toepassingen van indexen. 
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Uit Figuur D-11 blijkt dat sequentiële lijsten kunnen worden opgeslagen met behulp 
van elk van de drie bestandsorganisaties. Ze worden in de praktijk echter gewoonlijk 
bewaard in sequentiële bestanden. Linked lists en indexen kunnen zowel in index- 
sequentiële als in direct toegankelijke bestanden worden opgeslagen, maar DBMS- 
producten slaan ze vrijwel altijd op in direct toegankelijke bestanden. 


RRN _ Linkl Waardel Link2 Waarde2 Link3 


1 24e 4 

4 Indexset 

4 

R1 Adr1 R2 Adr2 R3 Adr3 Link 
101 1 1 Gegevens c of pointer 3 [ Gegevens of pointer | Gegevens of pointer 
102 |__10 | we J 13 | E Ze 
ke) e — 5 ! Sequenceset 
10e n - ee - DI (adressen van 
a 56 Î zn el gegevensrecords 
zijn weggelaten 

107 |_78 | 80 hes 
108 |_86_| 88 
109 1 | 92 


Figuur D-10 Een instantie van de B-tree in Figuur D-9 
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Figuur D-11 Overzicht van datastructuren en gegevensorganisaties voor het opslaan van geordende flat files 
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D2 Binaire relaties representeren 


In deze paragraaf laten we zien hoe elk van de drie speciale recordrelaties — boom:- 
structuren, enkelvoudige netwerken en complexe netwerken — met behulp van lin- 
ked lists en indexen kunnen worden gerepresenteerd. 


D2.1 Overzicht van mogelijke relaties tussen records 

Records kunnen op drie manieren aan elkaar worden gekoppeld. Een boomstructuur 
heeft een of meer een-op-veelrelaties, maar elke childrecord heeft maximaal één pa- 
rent. In Figuur D-r2 is een boomstructuur gerepresenteerd met daarin een instantie 
van gegevens binnen een faculteit. Er zijn diverse 1:N-relaties, maar elke child-record 
heeft maximaal één parent, zoals in Figuur D-13 is te zien. 


Figuur D-13 Schema van een boomstructuur met faculteitsgegevens 


Een eenvoudig netwerk is een verzameling records en de r:N-relaties daartussen. Het 
verschil met een boomstructuur is dat een child in een eenvoudig netwerk meer dan 
één parent kan hebben zolang de parents tenminste verschillende recordtypen zijn. 
In Figuur D-14 is een voorbeeld te zien van een eenvoudig netwerk met studenten, 
begeleiders en afstudeervakken en in Figuur D-15 is de bijbehorende relatiestructuur 
gerepresenteerd. 
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Een complex netwerk is ook een verzameling van records en relaties, maar de relaties 
zijn veel-op-veel, in plaats van een-op-veel. De relatie tussen studenten en vakken is 
hiervan een voorbeeld. In Figuur D-16 zie je een instantie van deze relatie en in Fi- 
guur D-17 is de algemene structuur afgebeeld. 

We hebben al eerder gezien dat we linked lists en indexen kunnen gebruiken om 
records in andere volgordes te verwerken dan de volgorde waarin ze fysiek zijn op- 
geslagen. We kunnen diezelfde datastructuren ook gebruiken om de relaties tussen 
records op te slaan en te verwerken. 


BEGELEIDERS AFSTUDEERVAKKEN 
Al A2 | A3 | M100 M200 
ON A 
ne Ed et 
ee eN En 
en Ee Ld 
1 


si) (ee) (5 sa) (Ss) 
STUDENTEN 
Figuur D-14 Voorbeeld van een eenvoudig netwerk 
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Figuur D.15 Algemene structuur van een eenvoudig netwerk 


Figuur D-17 Schema van een complex netwerk 
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D2.2 Boomstructuren representeren 

We kunnen sequentiële lijsten, linked lists en indexen gebruiken om boomstructu- 
ren weer te geven. Als we sequentiële lijsten gebruiken, moeten veel gegevens wor- 
den gedupliceerd. Bovendien worden sequentiële lijsten niet door DBMS-producten 


gebruikt om boomstructuren weer te geven. We zullen ons daarom alleen bezighou- 
den met linked lists en indexen. 


Boomstructuren representeren met linked lists 

In Figuur D-18 is een boomstructuur afgebeeld waarin de LEVERANCIER-records 
parents zijn en de FACTUUR-records als children fungeren. In Figuur D-19g zijn 
twee instanties van deze structuur te zien en in Figuur D-20 zijn alle LEVERAN- 
CIER- en FACTUUR-records naar een direct bestand geschreven. LEVERANCIER 
AA staat in relatief recordnummer 1 (RRN1) en LEVERANCIER BB staat in RRN2. 
De FACTUUR-records zijn opgeslagen in records die daarop volgen. Je ziet dat deze 
records niet in een bepaalde volgorde zijn opgeslagen, maar dat hoeft ook niet. 


LEVERANCIER Ù 


IS 
FACTUUR 
TEE REEN 


Figuur D-18 Voorbeeld van een boomstructuur met een relatie tussen LEVERANCIER- en FACTUUR-records 


LEVERANCIER AA LEVERANCIER BB Ù 


110 | 127.50 |} 
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Figuur D-19 Twee instanties van de boomstructuur LEVERANCIER-FACTUUR 


Record- 
nummer Recordinhoud 
1 | LEVERANCIER AA 
2 |LEVERANCIERBB | 
3 
4 
5 
6 
7 


Figuur D-20 Bestandsinhoud van de boomstructuren uit Figuur D-19 
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Het probleem hierbij is dat we uit dit bestand niet kunnen opmaken welke facturen 
bij welke leveranciers horen. Daarom voegen we aan elke record een linkveld toe. In 
dit veld slaan we het adres op van een bijbehorende record. We plaatsen bijvoorbeeld 
in het linkveld bij LEVERANCIER AA het adres van de eerste factuur die bij die le- 
verancier hoort. Dit is RRN7 dat overeenkomt met factuurnummer rro. Vervolgens 
laten we factuurnummer 1rro wijzen naar de volgende factuur die bij leverancier AA 
hoort. In dit voorbeeld is dat RRN3 waarin de gegevens staan van factuurnummer 
118. Om aan te geven dat er verder geen children, facturen in dit geval, meer zijn, 
plaatsen we een o in het linkveld voor RRN3. 

Deze techniek is te zien in Figuur D-21. Je ziet dat hetzelfde principe is toegepast 
op LEVERANCIER BB en de bijbehorende facturen. 

De structuur in Figuur D-21 is veel eenvoudiger aan te passen dan een sequen- 
tiële lijst met records. Als we bijvoorbeeld een nieuwe factuur met nummer rr wil- 
len toevoegen aan LEVERANCIER AA, voegen we de record toe aan het bestand en 
nemen we hem op in de linked list. Fysiek kan de record op elke willekeurige plek 
worden neergezet, maar waar moet de record logisch gezien worden geplaatst? De 
applicatie zal meestal een voorwaarde hebben — bijvoorbeeld dat children in toene- 
mende volgorde van factuurnummer moeten worden bewaard. Als dat het geval is, 
moeten we factuurnummer 1ro laten wijzen naar factuurnummer m1 (RRN8), en 
moeten we factuurnummer rr, de nieuwe factuur, laten wijzen naar factuurnum- 
mer 118 (RRN3). Deze aanpassing is uitgevoerd in Figuur D-22. 

Ook het verwijderen van een factuur gaat gemakkelijk. Als factuurnummer 114 
moet worden verwijderd, passen we de pointer aan die nu nog naar dit factuurnum- 
mer wijst. In ons voorbeeld is dat factuurnummer 112 met als RRN 5. We geven 
factuurnummer 112 de pointer die factuurnummer 114 had voordat het werd verwij- 
derd. Het resultaat hiervan is dat factuurnummer 112 wijst naar factuurnummer 119 
(zie Figuur D-23). Dit is te vergelijken met het verwijderen van een schakel uit een 
ketting en het vervolgens weer aan elkaar lassen van de twee delen die daardoor zijn 
ontstaan. 


Relatief 
record- Link- 
nummer Recordinhoud veld 
1 [LEVERANCIER AA 
2 [LEVERANCIER BB 
3 
4 119 8.95 
5 112 18.95 
6 114 27.50 
7 127.50 


Figuur D-21 Instanties van een boomstructuur, gerepresenteerd met linked lists 
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Relatief 
record- Link- 
nummer Recordinhoud veld 
1 
2 
3 
4 
5 
6 
7 
8 Ingevoegde 


L record 
Figuur D-22 Resultaat na invoegen van factuurnummer 111 in het bestand uit Figuur D-21 


Relatief 

record- Link- 

nummer Recordinhoud veld 
4 
2 
3 
: 
5 : 
6 Verwijderde 
7 ne En Mk 
8 


EEN 


Figuur D-23 Het verwijderen van factuurnummer 114 uit het bestand in Figuur D-22 


Boomstructuren representeren met indexen 
Een boomstructuur kan ook eenvoudig met behulp van indexen worden gerepresen- 
teerd. Hierbij wordt elke r:N-relatie als een index opgeslagen. Deze lijsten worden 
vervolgens gebruikt om parents en children bij elkaar te zoeken. 

Als we nog even gebruikmaken van de LEVERANCIER- en FACTUUR-records 
in Figuur D-21, zien we dat LEVERANCIER AA (in RRN1) de factuurnummers 110 
(RRN7) en 118 (RRN3) bezit. RRNr is dus de parent van RRN7 en RRN3. We kunnen 
dit gegeven representeren met de index in Figuur D-24. In de lijst wordt het adres 
van een parent gekoppeld aan de adressen van zijn children. 

Als een boomstructuur verscheidene r:N-relaties bevat, moeten er net zoveel in- 
dexen worden bijgehouden, dus een voor elke relatie. Zo zijn er voor de structuur in 
Figuur D-13 vijf indexen nodig. 


D2.3 Eenvoudige netwerken representeren 
Eenvoudige netwerken kunnen net als boomstructuren worden gerepresenteerd 
met behulp van linked lists en indexen. 


Eenvoudige netwerken representeren met linked lists 
In Figuur D-25 is een voorbeeld te zien van een eenvoudig netwerk. Dat het hier om 


een eenvoudig netwerk gaat, blijkt uit het gegeven dat alle relaties van het type r:N 
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zijn en de VERZENDING-records twee parents van een verschillend type hebben. 
Elke VERZENDING heeft een KLANT-parent en een TRUCK-parent. De relatie tus- 
sen KLANT en VERZENDING is r:N, omdat bij een klant verscheidene verzendin- 
gen kunnen horen. De relatie tussen TRUCK en VERZENDING is ook r:N, omdat 
er in één truck veel verzendingen kunnen worden vervoerd. (We veronderstellen dat 
een VERZENDING altijd in haar geheel in één TRUCK past.) In Figuur D-26 zijn 
voorbeeldgegevens bij dit netwerk afgebeeld. 

Dit eenvoudige netwerk kan met behulp van linked lists worden gerepresenteerd 
door per r:N-relatie een verzameling pointers op te stellen. In dit voorbeeld is er een 
serie pointers die KLANTen met VERZENDINGen verbindt en een serie pointers 
die TRUCKs met VERZENDINGen verbindt. ledere KLANT en elke TRUCK heeft 
een pointer die wijst naar de eerste VERZENDING van deze KLANT of TRUCK. Ver- 
der bezit elke VERZENDING twee pointers: een voor de volgende VERZENDING 
van deze KLANT en een voor de volgende VERZENDING in de TRUCK (zie Figuur 
D-27). 


Parent- Child- 
record record 


Figuur D-25 De structuur van eenvoudig netwerk 


EON 


Figuur D-26 Instantie van het eenvoudige netwerk in Figuur D-25 
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In een eenvoudig netwerk komen minstens twee r:N-relaties voor, die elk kunnen 
worden gerepresenteerd met indexen, op de manier die we in de paragraaf over 
boomstructuren hebben gezien. Kijk bijvoorbeeld eens naar het eenvoudige netwerk 
in Figuur D-25. Deze heeft twee r:N-relaties: een tussen TRUCK en VERZENDING 
en een tussen KLANT en VERZENDING. We kunnen elk van deze relaties opslaan 
als een index. Figuur D-28 toont de twee indexen die nodig zijn voor het represente- 


ren van het voorbeeld in Figuur D-26. Ga ervan uit dat de records op dezelfde posi- 
ties staan als in Figuur D-27. 


D2.4 Complexe netwerken representeren 

Complexe netwerken kunnen fysiek op tal van manieren worden gerepresenteerd. 
Ze kunnen bijvoorbeeld worden opgedeeld in boomstructuren of eenvoudige net- 
werken, waarna deze eenvoudigere structuren kunnen worden gerepresenteerd met 
behulp van een van de zojuist besproken technieken. Ze kunnen ook direct wor- 
den gerepresenteerd met behulp van indexen. Linked lists worden door geen enkel 
DBMS-product gebruikt om complexe netwerken rechtstreeks weer te geven. In de 
praktijk worden complexe netwerken bijna altijd gesplitst in eenvoudiger structuren 
— we zullen daarom alleen die werkwijze bespreken. 

Complexe netwerken worden dus veelal opgedeeld in eenvoudige netwerken die 
vervolgens met linked lists of indexen worden gerepresenteerd. Bij een complex net- 
werk is echter sprake van een relatie tussen twee records, terwijl bij een eenvoudig 
netwerk altijd drie records zijn betrokken. We zullen dus een derde recordtype in het 


leven moeten roepen om het complexe netwerk op te kunnen delen in een eenvou- 
dig netwerk. 


Relatief 
record- 


nummer Recordinhoud Link Velden 


eN 


o@ooNPDA BWN 
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EEE EFC VREES 


KLANT- TRUCK- 
links links 


Figuur D-27 Weergave van een eenvoudig netwerk met linked lists 
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Klant- Verzending- Truck- _ Verzending- 
record record record record 

1 6 3 6 

df Ee) 3 7 

2 7 4 g 

2 8 5 | 8 

2 10 5 10 


Figuur D-28 Weergave van eenvoudig netwerk met indexen 


De record die wordt gemaakt als een complex netwerk wordt opgedeeld in een een- 
voudig netwerk wordt een intersectierecord genoemd. In het geval van het STUDENT/ 
VAK-netwerk bevat de intersectierecord een unieke sleutel uit een STUDENT-record 
en een unieke sleutel uit een bijbehorende VAK-record. De intersectierecord bevat 
geen andere applicatiedata, maar kan wel een of meer linkvelden hebben. In Figuur 
D-29 is de algemene structuur van deze relatie te zien. In Figuur D-3o is een instan- 
tie van de STUDENT/VAK-relatie afgebeeld, waarbij wordt verondersteld dat de re- 
cordnamen (zoals Sr, S2 en Cr) uniek zijn. 

Merk op dat de relatie tussen STUDENT en de intersectierecord en die tussen 
VAK en de intersectierecord beide van het type r:N zijn. We hebben op deze manier 
dus een eenvoudig netwerk gecreëerd dat vervolgens met behulp van linked lists of 
indexen kan worden gerepresenteerd. In Figuur D-31 is het resultaat te zien bij ge- 
bruik van linked lists. 


D2.5 Overzicht van relatierepresentaties 

In Figuur D-32 zijn de verschillende representaties van recordrelaties nog eens 
samengevat. Boomstructuren kunnen worden representeren met behulp van se- 
quentiële lijsten (hoewel we die methode niet besproken hebben), linked lists of 
indexen. Sequentiële lijsten worden niet in DBMS-producten toegepast. Een eenvou- 
dig netwerk kan worden gesplitst in boomstructuren en vervolgens als zodanig wor- 
den gerepresenteerd, maar het kan ook direct worden gerepresenteerd met behulp 
van linked lists of indexen. Een complex netwerk kan ten slotte worden opgesplitst in 
boomstructuren of eenvoudige netwerken (met behulp van intersectierecords), maar 
kan ook direct worden gerepresenteerd met behulp van indexen. 


STUDENT Ù 
NETTEN ENNE SE 


STUDENT-VAK 
intersectierecord 


Figuur D-29 Het ontleden van een complex netwerk in een eenvoudig netwerk 
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Figuur D-30 Instantie van STUDENT /VAK-relatie met gebruik van intersectierecords 


Relatief 
record- 
nummer Recordinhoud Link velden 


STUDENT- VAK- 
links links 


Figuur D-31 Een instantie van het netwerk uit Figuur D-30 
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Complex 


En netwerk 
Decompositie 


Record- Eenvoudig 
relaties Netwerk Î 
Decompositie 
Gegevens- Sequentiële 
structuren lijst 
Bestands- Sequentieel Direct 
organisaties 
Nn EN EEE EEn 
——__ Gebruikelijk 
Ee in: Zeldzaam 


Figuur D-32 Overzicht van recordrelaties, datastructuren en bestandsorganisaties 


D3 Secundaire sleutels representeren 


In veel gevallen duidt het woord key of sleutel op een veld (of velden) waarvan de 
waarde op unieke wijze een record identificeert. Dit wordt meestal de primaire sleutel 
genoemd. Soms hebben applicaties voor de toegang en verwerking van records een 
zogenaamde secundaire sleutel (secondary key) nodig. Dit is een sleutel die afwijkt 
van de primaire sleutel. Secundaire sleutels kunnen uniek zijn (zoals de Naam van 
een leraar), maar kunnen ook niet-uniek zijn (zoals de Postcode van een klant). In 
deze paragraaf zullen we de verzameling records met dezelfde waarde voor een be- 
paalde secundaire sleutel een set noemen, bijvoorbeeld een set KLANT-records met 
Postcode 9804. 

Voor het representeren van secundaire sleutels worden zowel linked lists als in- 
dexen gebruikt. Linked lists zijn echter alleen geschikt voor niet unieke secundaire 


sleutels, terwijl indexen voor zowel unieke als niet unieke secundaire sleutels kun- 
nen worden gebruikt. 
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D3.1 Secundaire sleutels representeren met linked lists 

In Figuur D-33 is een voorbeeld te zien met KLANT-records. De primaire sleutel is 
Rekeningnummer en de secundaire sleutel is Kredietlimiet. Mogelijke waarden van 
Kredietlimiet zijn 5oo, 7oo en rooo. Er bestaat dus voor elke kredietlimietwaarde 
een set records. 

Als we deze sleutel met behulp van linked lists willen representeren, voegen we 
een linkveld toe aan de KLANT-records. Binnen dit linkveld creëren we voor elke set 
records een linked list. In Figuur D-34 is een database te zien met elf klanten, waar- 
bij kortheidshalve alleen Rekeningnummer en Kredietlimiet zijn afgebeeld. Aan de 
records is een linkveld toegevoegd. Ga ervan uit dat één databaserecord één fysieke 
record inneemt in een direct bestand via relatieve recordadressering. 

We moeten drie pointers instellen om te kunnen bepalen waar elke linked list 
begint. Deze pointers noemen we koppen (‘heads’) en deze worden apart van de ge- 
gevens opgeslagen. De kop van de linked list € soo is RRNr. Record r is verbonden 
met record 2, die op zijn beurt wijst naar record 7. Record 7 heeft de waarde o in zijn 
linkveld staan, dus deze record staat aan het eind van de lijst. De kredietlimietset van 
€ 5oo bestaat dus uit de records 1, 2 en 7. De set € 7oo bestaat uit records 3, 5 en 10 
en de set € rooo wordt gevormd door de records 4, 6, 8, 9 en rr. 


Rekening- Krediet- | Openstaand 
nummer limiet 


Primaire sleutel Secundaire sleutel 
Figuur D-33 KLANT-record 


Relatief 


record- Rekening- Krediet- Overige 
nummer en nummer _ limiet gegevens 


1 KOP-500 = 1 
KOP-700 = 3 
KOP-1000 = 4 


OON WN 


kek 


TIENEN EELS 


Figuur D-34 Weergave van de secundaire sleutel Kredietlimiet met behulp van linked list 


Een query als: ‘Hoeveel klanten met een kredietlimiet van rooo hebben een Open- 
staand bedrag van meer dan goo?’ kan eenvoudig worden beantwoord door de lin- 
ked list voor kredietwaarde rooo door te werken. Alleen de records in de rooo-set 
moeten uit het bestand worden gelezen en verwerkt. Het voordeel van deze aanpak 
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zal je misschien niet helemaal duidelijk zijn, omdat het hier een klein voorbeeld be- 
treft, maar als we bijvoorbeeld te maken hebben met honderdduizend klanten waar- 
van er maar honderd in de rooo-set zitten, hoeven er bij gebruik van een linked list 
maar honderd records te worden doorgewerkt. Zonder linked list hadden ze alle hon- 
derdduizend moeten worden doorgewerkt. Het gebruik van de linked list bespaart 
dus 99.goo leesacties! 

Linked lists zijn niet voor elke applicatie met secundaire sleutels een oplossing. 
Vooral als de records binnen een set niet sequentieel worden verwerkt, zijn linked 
lists inefficiënt. Als het bijvoorbeeld vaak nodig is om de tiende, honderdtwintigste 
of nde record in de soo-set te zoeken, laat de verwerking te wensen over. Voor het 
rechtstreeks benaderen van records zijn linked lists geen geschikte oplossing. 

De benadering via linked lists is bovendien ongewenst als de applicatie verlangt 
dat secundaire sleutels op dynamische wijze worden gecreëerd of vernietigd. Elke 
keer dat er een nieuwe sleutel wordt gecreëerd, moet er aan elke record een linkveld 
worden toegevoegd. Vaak moet hiervoor de database worden gereorganiseerd en dit 
is een tijdrovend en kostbaar proces. | 

Als de waarden van een secundaire sleutel uniek zijn, heeft elke linked list een 
lengte van 1 en bestaat er dus voor elke record in de database een aparte linked list. 
Dit is duidelijk een onwerkbare situatie en daarom kunnen linked lists niet voor 
unieke sleutels worden gebruikt. Stel dat de KLANT-records een ander uniek veld 
bevatten, bijvoorbeeld SofiNummer. Als we proberen deze unieke secundaire sleutel 
met behulp van een linked list weer te geven, wordt elk SofiNummer een aparte lin- 
ked list. Elke linked list bevat dan precies één gegevenselement, namelijk de afzon- 
derlijke record met het aangegeven SofiNummer. 


D3.2 Secundaire sleutels representeren met indexen 

Een tweede techniek voor het representeren van secundaire sleutels is via indexen. 
Voor elke secundaire sleutel wordt één index gecreëerd. De aanpak is afhankelijk van 
de vraag of de sleutelwaarden uniek of niet uniek zijn. 


Unieke secundaire sleutels 

Stel dat de KLANT-records in Figuur D-33 naast de getoonde velden ook nog een Sofi- 
Nummer zouden bevatten. Als we de klantgegevens met het SofiNummer als sleutel 
willen bereiken, stellen we een index op voor het veld SofiNummer. In Figuur D-35(a) 
zijn voorbeeldgegevens te zien en in Figuur D-35(b) staat de bijbehorende index. In 
deze index worden relatieve recordnummers als adressen gebruikt, maar we zouden 
hiervoor ook Rekeningnummers kunnen gebruiken. In dat laatste geval moet het 
DBMS het gewenste SofiNummer in de index opsporen, het overeenkomstige Re- 
keningnummer achterhalen en dat vervolgens omzetten in een relatief recordadres. 


Niet unieke secundaire sleutels 


Indexen kunnen ook worden gebruikt voor het representeren van niet unieke secun- 
daire sleutels. Maar omdat elke set verwante records een onbekend aantal elementen 
kan bevatten, hebben de sets in de index een variabele lengte. In Figuur D-36 staat de 
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index voor Kredietlimiet-set met KLANT-gegevens. De 5oo- en 7oo-set hebben beide 
drie Rekeningnummers en de rooo-set heeft er vijf. 


Relatief Relatieve 
record- _Rekening- Krediet- record- 
nummer nummer limiet SofiNummer SofiNummer _nummer 


500 
000-01-0005 
000-01-0009 
[_004 | 1000 | 000-01-0003 | 
KT Ne PT 

(a) (b) 


Figuur D-35 Een unieke secundaire sleutel representeren met indexen: (a) voorbeeldgegevens KLANT (met 
SofiNummer) en (b) index met SofiNummer als secundaire sleutel 


1 000-01-0001 
000-01-0003 
000-01-0005 


000-01-0009 


4 
4 4 
2 2 
3 3 


Krediet- Rekeningnummer 
limiet 
_500__|101f301}7os| | | 
L_7oo | 203}204|409| | | 
\_1000__ | 004 | 905 | 207 | 309 | 210 | 


Figuur D-36 Index voor Kredietlimiet-sleutel in Figuur D-33 


In de praktijk is het representeren en verwerken van niet unieke secundaire sleutels 
vrij ingewikkeld. Verschillende DBMS-producten maken gebruik van verschillende 
methoden. Een veelgebruikte methode maakt gebruik van een waardetabel (value 
table) en een instantietabel (occurrence table). Elk item in de waardetabel bestaat 
uit twee velden. In het eerste veld staat de waarde van de secundaire sleutel. Voor de 
Kredietlimiet-sleutel in KLANT zijn de waarden soo, 7oo en rooo. Het tweede veld 
bevat een pointer naar de instantietabel. De instantietabel bevat recordadressen en 
de records met dezelfde waarde in het secundaire sleutelveld staan samen in de ta- 
bel. Figuur D-37 toont de waarde- en instantietabellen voor de Kredietlimiet-sleutel. 

Om records met een bepaalde secundaire sleutelwaarde te vinden, wordt eerst 
in de waardetabel gezocht naar de waarde. Vervolgens wordt de pointer gevolgd 
naar de instantietabel en worden de adressen opgehaald van de records met deze 
sleutelwaarden. 

Als een nieuwe record aan het bestand wordt toegevoegd, moet het DBMS de in- 
dexen voor elk secundaire sleutelveld aanpassen. In het geval van niet unieke sleu- 
tels moet het DBMS nagaan of de nieuwe recordsleutelwaarde in de waardetabel is 
opgenomen — als dat zo is, wordt het nieuwe recordadres toegevoegd op de juiste 
plaats in de instantietabel. Als de sleutelwaarde nog niet voorkomt, moeten nieuwe 
gegevens zowel aan de waarde- als de instantietabel worden toegevoegd. 

Als een record wordt verwijderd, moet het adres daarvan uit de instantietabel 
worden verwijderd. Als dit het laatste adres was dat in de instantietabel stond, moe- 
ten de bijbehorende gegevens in de waardetabel ook worden verwijderd. 

Bij het wijzigen van de waarde van een secundaire sleutel, moet het recordadres 
worden verwijderd uit de ene instantietabel en aan een andere worden toegevoegd. 


574 


0” 


BIJLAGE D | DATASTRUCTUREN VOOR OATABASEVERWERKING 


Als deze waarde nog niet voorkomt, moet de nieuwe sleutelwaarde aan de waardeta- 
bel worden toegevoegd. 

Het werken met indexen voor het representeren van secundaire sleutels is veel 
handiger dan de aanpak met linked lists. Sets kunnen direct worden verwerkt — de 
derde record in een set kan bijvoorbeeld worden opgehaald zonder dat eerst de eerste 
of tweede moet worden verwerkt. Verder is het mogelijk om secundaire sleutels dy- 
namisch te creëren en te verwijderen. Er worden geen wijzigingen uitgevoerd in de 
records zelf — het DBMS creëert alleen extra waarde- en instantietabellen. Bovendien 
kunnen unieke sleutels op een efficiënte wijze worden verwerkt. 

De nadelen van de indexmethode zijn dat meer geheugenruimte nodig is (tabel- 
len gebruiken meer overheadgegevens dan pointers) en dat de programmeertaak 
van het DBMS zelf complexer is. Dit betekent niet dat het ontwikkelen van applicaties 
moeilijker is, maar wel dat het lastiger is om DBMS-software te schrijven die indexen 
verwerkt dan software waarin met linked lists wordt gewerkt. Verder is het zo dat 
wijzigingen meestal wat langzamer worden verwerkt, omdat er nogal wat lees- en 
schrijfbewerkingen moeten worden uitgevoerd om de waarden in de instantietabel- 
len te benaderen en bij te werken. 


Waardetabel Instantietabel 


Rekeningnummer 
A. 


Kredietlimiet 

500 705 | __ | 

700 == 203 | 204 [| 409 

1000 004 | 905 | 207 | 309 | 210 
Nee EEN 


Figuur D-37 Waarde- en instantietabel voor de Kredietlimiet-sleutel in Figuur 0-33 


Samenvatting 


In deze bijlage hebben we een overzicht gegeven van de datastructuren die voor 
databaseverwerking worden gebruikt. Een flat file is een bestand zonder herhaalde 
gegevensgroepen. Flat files kunnen worden gerangschikt door de records fysiek ge- 
ordend in sequentiële lijsten te plaatsen, door een linked list te gebruiken (waarbij 
aan elke datarecord een pointer wordt gekoppeld die wijst naar een andere logisch 
gerelateerde record), of door middel van een index (een aparte tabel waarin pointers 
naar verwante records staan). Een B-tree is een speciale toepassing van een index. 
Sequentiële lijsten, linked lists en indexen (of geïnverteerde lijsten) zijn elemen- 
taire datastructuren. Deze datastructuren kunnen worden gebruikt voor het repre- 
senteren van relaties tussen records en voor het bijhouden van secundaire sleutels. 
De drie elementaire recordstructuren — boomstructuren, eenvoudige netwer- 
ken en complexe netwerken — kunnen worden gerepresenteerd met behulp van 
linked lists en indexen. Eenvoudige netwerken kunnen worden opgesplitst in boom- 
structuren en als zodanig worden gerepresenteerd — complexe netwerken kunnen 
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worden opgedeeld in eenvoudige netwerken, waaraan een intersectierecord wordt 
toegevoegd, en aldus worden gerepresenteerd. 

Secundaire sleutels (secondary keys) worden gebruikt om gegevens via een an- 
der veld dan via de primaire sleutel te benaderen. Een secundaire sleutel kan uniek 
of niet uniek zijn. Niet unieke secundaire sleutels kunnen worden gerepresenteerd 
met linked lists en indexen. Unieke secundaire sleutels kunnen alleen met behulp 
van indexen worden gerepresenteerd. 


Herhalingsvragen 


D.r Geef de definitie van een flat file. Bedenk zelf een voorbeeld van een flat file en 
van een bestand dat geen flat file is. 

D.2 Laat zien hoe sequentiële lijsten kunnen worden gebruikt om het bestand uit 
vraag D.r in twee volgordes tegelijk bij te houden. 

D.3 Laat zien hoe linked lists kunnen worden gebruikt om het bestand uit vraag 
D.r in twee volgordes tegelijk bij te houden. 

D.4 Laat zien hoe geïnverteerde lijsten kunnen worden gebruikt om het bestand 

uit vraag D.r in twee volgordes tegelijk bij te houden. 

D.5 Geef een definitie van een boomstructuur en geef een voorbeeld. 

D.6 Geef een gegevensvoorbeeld bij de boomstructuur uit vraag D.5. 

D.7 Representeer het gegevensvoorbeeld uit vraag D.6 met linked lists. 

D.8 Representeer het gegevensvoorbeeld uit vraag D.6 met indexen. 

D.g Geef een definitie van een eenvoudig netwerk en geef een voorbeeld van deze 
structuur. 

D.ro Geef een gegevensvoorbeeld bij het netwerk uit vraag D.9. 

Dr Representeer het gegevensvoorbeeld uit vraag D.ro met linked lists. 

D.12 Representeer het gegevensvoorbeeld uit vraag D.ro met indexen. 

D.13 Geef een definitie van een complex netwerk en geef een voorbeeld van deze 
structuur. 

D.14 Geef een gegevensvoorbeeld bij het netwerk uit vraag D.13. 

D.r5 Splits het complexe netwerk in vraag D.14 op in een eenvoudig netwerk en re- 
presenteer een gegevensvoorbeeld met behulp van indexen. 

D.16 Wat is het verschil tussen primaire en secundaire sleutels? 

D.17 Wat is het verschil tussen unieke en niet unieke sleutels? 

D.18 Definieer een bestand met een unieke secundaire sleutel. Representeer een ge- 
gevensvoorbeeld van dat bestand met behulp van een index voor de secundaire 
sleutel. 

D.1g Definieer een niet unieke secundaire sleutel voor het bestand uit vraag D.1ê. 
Representeer een gegevensvoorbeeld van dat bestand met behulp van een lin- 
ked list voor de secundaire sleutel. 

D.20 Voer dezelfde opdracht uit als in vraag D.19, maar maak nu gebruik van een 
index om de secundaire sleutel voor te stellen. 


576 


BIJLAGE D | DATASTRUCTUREN VOOR DATABASEVERWERKING 


D.2r Schrijf een algoritme voor het produceren van een rapport met de ID's van stu- 
denten per vak en maak daarbij gebruik van de linked liststructuur in Figuur 
D-4. 

D.22 Schrijf een algoritme waarmee records aan de structuur in Figuur D-4 worden 
toegevoegd. De resulterende structuur moet lijken op die in Figuur D-5. 

D.23 Schrijf een algoritme voor het produceren van een rapport met de ID's van 
studenten per vak en maak daarbij gebruik van de indexstructuur in Figuur D- 
8(a), (b) en (c). 

D.24 Schrijf een algoritme waarmee records aan de structuur in Figuur D-8(a) wor- 
den toegevoegd. Zorg dat de bijbehorende indexen in Figuur D-8(b) en (c) ook 
worden aangepast. 

D.25 Schrijf een algoritme voor het verwijderen van een record uit de structuur in 
Figuur D-34, waarbij een secundaire sleutel met een linked list wordt gerepre- 
senteerd. Als alle records voor een van de kredietlimietcategorieën (bijvoor- 
beeld categorie 1ooo) worden verwijderd, moet dan de pointer aan het begin 
van de lijst ook worden verwijderd? Waarom wel/niet? 

D.26 Schrijf een algoritme voor het invoegen van een record in de structuur in Fi- 
guur D-34. Stel dat de nieuwe record een kredietlimietwaarde heeft die nog 
niet voorkomt. Moet de record worden toegevoegd en moet een nieuwe linked 
list worden opgesteld, of moet de record worden geweigerd? Wie moet die be- 
slissing nemen? 
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Bijlage £ 
Het semantische objectmodel 


In deze bijlage bespreken we het semantische objectmodel, dat net als het in hoofd- 
stuk 2 en 3 besproken E-R-model wordt gebruikt voor het creëren van datamodellen. 
Zoals is weergegeven in figuur E‚1 ondervraagt het ontwikkelteam gebruikers, ana- 
lyseert het de rapporten, formulieren en query’s van gebruikers en construeert het aan 
de hand hiervan een model van de gebruikersgegevens. Dit datamodel wordt later om- 
gezet in een databaseontwerp. 

Deze vorm van het datamodel is afhankelijk van de constructies die worden gebruikt 
om het te bouwen. Als er een E-R-model wordt gehanteerd, zal het model entiteiten, 
relaties enzovoort hebben. Als een semantisch model wordt ingezet, zal het model se- 
mantische objecten en verwante constructies hebben, die hier aan bod komen. 

We kunnen het E-R-model en het semantische objectmodel beschouwen als len- 
zen waardoor de databaseontwikkelaars kijken als ze de gegevens van de gebruikers 
bestuderen en documenteren. Beide lenzen werken en ze resulteren beide uiteindelijk 
in een databaseontwerp. Ze maken echter gebruik van verschillende lenzen om tot dat 
ontwerp te komen en omdat de lenzen verschillende afbeeldingen creëren, bestaat 
de kans dat de geproduceerde ontwerpen niet precies aan elkaar gelijk zijn. Als je een 
database gaat ontwikkelen, moet je beslissen welke benadering je gaat hanteren, net 
zoals een fotograaf een bepaalde lens moet selecteren. Elke benadering heeft haar 
sterke en zwakke punten, die we aan het eind van deze bijlage bespreken. 
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Het semantische objectmodel kwam het eerst ter sprake in de derde editie van dit 
boek, in 1988. Het is gebaseerd op concepten die zijn ontwikkeld en gepubliceerd 
door Codd en door Hammer en McLeod.' Het semantische objectmodel is een data- 
model. Het is anders dan objectgeoriënteerde databaseverwerking, een onderwerp 
dat we in hoofdstuk 1 hebben besproken. Je zult hier zien in welk opzicht de doelstel- 
lingen, mogelijkheden en constructies van semantische objectmodellering verschil- 
len van objectgeoriënteerde databaseverwerking. 


Entiteit-relatiemodel 


Entiteiten 
en 
Relaties 


Database- 
ontwerp 


Ì „Semantisch Representatie van 
objectmodel gebruikersgegevens 
Rapporten, formulieren en_“ 8 Semantische Database- 
query’s van gebruikers SS objecten ontwerp 


Figuur E-1 Verschillende datamodellen gebruiken voor het ontwerpen van een database 


E1 Semantische objecten 


Het doel van een databaseapplicatie is formulieren, rapporten en query’s te verschaf 
fen zodat de gebruikers entiteiten of objecten kunnen bijhouden die voor hun werk 
belangrijk zijn. In de beginstadia van het ontwikkelen van een database moet wor- 
den vastgesteld welke zaken in de database moeten zijn vertegenwoordigd, moeten 
de kenmerken van die zaken worden opgegeven en moeten de onderlinge relaties 
worden vastgesteld. 

In hoofdstuk 2 en 3 verwezen we naar deze zaken als entiteiten. In deze bijlage 
duiden we ze aan met de term semantische objecten of soms gewoon als objecten. 
Het woord semantisch betekent betekenis en een semantisch object is een object dat 
de betekenis van de gebruikersgegevens gedeeltelijk modelleert. Semantische objec- 
ten modelleren de ideeën van de gebruikers beter dan het E-R-model. We hanteren 


1 _E.F.Codd, ‘Extending the Relational Model to Capture More Meaning’, ACM Transactions on Database 
Systems, december 1976, pp. 397-424 en Michael Hammer en Dennis McLeod, ‘Database Descrip- 
tion with SDM: A Semantic Database Model’, ACM Transactions on Database Systems, september 


19êr, pp. 351-386. 
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het bijvoeglijk naamwoord semantisch met het woord object om onderscheid te ma- 
ken tussen de objecten die in deze bijlage aan bod komen en de objecten die worden 
gedefinieerd in objectgeoriënteerde programmeertalen (OOP-talen). 


E1.1 Semantische objecten definiëren 


Entiteiten en objecten lijken deels op elkaar en wijken in bepaalde opzichten van el- 
kaar af. We beginnen met de overeenkomsten tussen de twee. Een semantisch object 
is een representatie van een identificeerbaar iets in de werkomgeving van de gebrui- 
kers. Formeler uitgedrukt: een semantisch object is een benoemde verzameling attri- 
buten die een aparte identiteit voldoende beschrijven. 

Semantische objecten worden net als entiteiten gegroepeerd in klassen. Een ob- 
jectklasse heeft een naam die haar onderscheidt van andere klassen en die over- 
eenkomt met de namen van de zaken die zij vertegenwoordigt. Een database die 
gebruikers ondersteunt bij het werken met studentenrecords heeft dus een object- 
klasse die STUDENT heet. Merk op dat namen van objectklassen net als namen van 
entiteitsklassen met hoofdletters worden gespeld. Een bepaald semantisch object is 
een instantie van de klasse. “Willem Jansen’ is dus een instantie van de STUDENT- 
klasse en ‘Financiële Administratie’ is een instantie van de klasse AFDELING. 

Een object heeft net als entiteiten een verzameling attributen. Elk attribuut ver- 
tegenwoordigt een kenmerk van de vertegenwoordigde identiteit. Zo kan het STU- 
DENT-object bijvoorbeeld attributen hebben zoals Naam, Huisadres, Studieadres, 
GebDatum, Afstudeerdatum en Hoofdvak. Deze verzameling attributen is ook een 
voldoende beschrijving, wat betekent dat de attributen alle kenmerken vertegenwoor- 
digen die de gebruikers voor hun werk nodig hebben. Zoals we aan het eind van 
hoofdstuk 3 hebben vermeld, hebben zaken in de wereld om ons heen een oneindige 
reeks kenmerken — we kunnen ze niet allemaal weergeven. In plaats daarvan nemen 
we alleen die kenmerken die gebruikers nodig hebben om hun taken succesvol uit 
te voeren. Voldoende beschrijving betekent ook dat de objecten op zichzelf compleet 
zijn. Alle gegevens die zijn vereist over een KLANT staan bijvoorbeeld in het KLANT- 
object, zodat we nergens anders hoeven te zoeken om gegevens over KLANTen te 
vinden. 

Objecten vertegenwoordigen aparte identiteiten — dat wil zeggen, ze zijn iets wat 
gebruikers herkennen als onafhankelijk en apart en wat gebruikers willen bijhou- 
den en rapporteren. Deze identiteiten zijn de zelfstandige naamwoorden waarover 
de informatie moet worden geproduceerd. Om beter te begrijpen wat de term aparte 
identiteit inhoudt, brengen we in herinnering dat er een verschil is tussen objecten 
en objectinstanties. KLANT is de naam van een object en ‘KLANT 12345’ is de naam 
van een instantie van een object. Als we zeggen dat een object een aparte identiteit 
vertegenwoordigt, bedoelen we dat gebruikers elke instantie van een object als uniek 
en identificeerbaar beschouwen. 

Merk ten slotte op dat de identiteiten die de objecten vertegenwoordigen niet 
per se fysiek aanwezig hoeven te zijn. MEDEWERKERS bijvoorbeeld bestaan fysiek, 
maar ORDERs niet. Orders zijn zelf modellen van een contractuele overeenkomst 
om bepaalde goederen of diensten te leveren onder bepaalde voorwaarden. Het zijn 
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geen fysieke zaken, maar voorstellingen van overeenkomsten. Iets hoeft dus niet per 
se fysiek te zijn om als een object te kunnen worden aangemerkt — het moet alleen 
identificeerbaar zijn in de gedachten van de gebruikers. 


E1.2 Attributen 

Semantische objecten hebben attributen die hun kenmerken definiëren. Er zijn drie 
typen attributen. Enkelvoudige attributen kennen één element. Voorbeelden daar- 
van zijn DatumInDienst, Factuurnummer en Verkooptotaal. Groepsattributen zijn 
samenstellingen van andere attributen. Een voorbeeld is Adres, dat is opgebouwd uit 
de attributen {Straat, Plaats, Provincie, Postcode}. Een ander voorbeeld is Volledige- 
Naam, dat de attributen (Voornaam, Tweedelnitiaal, Achternaam} bevat. Semanti- 
sche objectattributen zijn attributen die een relatie realiseren tussen het ene en het 
andere semantische object. 

Om beter te begrijpen wat hiermee wordt bedoeld, werpen we een blik op Figuur 
E-2(a). Dit is een voorbeeld van een semantisch objectdiagram of objectdiagram. 
Zulke diagrammen worden gehanteerd door ontwikkelteams om de structuren van 
objecten samen te vatten en om ze visueel te presenteren. Objecten worden weerge- 
geven in staande rechthoeken. De naam van het object staat bovenaan en attributen 
staan in volgorde onder de naam van het object. 


VAKGROEP 
ID Vakgroepnaam 


VAKGROEP. 
ID Vakgroepnaam 1.1 


Campusadres Campusadres 


Gebouw 
Kantoornummer 


Gebouw 1.1 
Kantoornummer 1.1 
0.1 


Telefoonnummer Telefoonnummer 1.N 


Faxnummer 


VAKGROEP 
PROFESSOR 
STUDENT 


Faxnummer 0.1 


(a) 


Figuur E-2 Objectdiagram voor VAKGROEP: (a) het object VAKGROEP en (b) het object VAKGROEP met 
kardinaliteiten 


Het VAKGROEP-object bevat een voorbeeld van elk van de drie typen attributen. 
Vakgroepnaam, Telefoonnummer en Faxnummer zijn enkelvoudige attributen 
die elk één bepaald gegevenselement vertegenwoordigen. Vakgroepadres is een 
groepsattribuut dat de enkelvoudige attributen Gebouw en Kantoornummer bevat. 
FACULTEIT, PROFESSOR en STUDENT ten slotte zijn elk semantische objectattri- 
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buten, wat betekent dat deze zijn verbonden met en een logisch onderdeel zijn van 
VAKGROEP. 

De objectattributen, oftewel objectlinks zoals ze soms worden genoemd, houden 
in dat wanneer een gebruiker denkt aan een VAKGROEP, hij of zij niet alleen denkt 
aan de Vakgroepnaam, het Vakgroepadres, Telefoonnummer en Faxnummer, maar 
ook aan de FACULTEIT, PROFESSORen en STUDENTen die tot die vakgroep beho- 
ren. Omdat FACULTEIT, PROFESSOR en STUDENT ook objecten zijn, bevat het 
volledige datamodel ook hiervoor objectdiagrammen. Het FACULTEIT-object bevat 
attributen van de faculteit, het PROFESSOR-object bevat attributen van de faculteit 
en het STUDENT-object bevat attributen van de studenten. 


Kardinaliteit van attributen 


Elk attribuut in een semantisch object kent een minimum- en een maximumkardi- 
naliteit. De minimumkardinaliteit geeft aan hoeveel instanties van het attribuut er 
moeten bestaan, wil het object geldig zijn. Dat aantal is meestal o of 1. Als het o is, 
hoeft het attribuut niet per se een waarde te hebben. Als het 1 is, is dat wel het geval. 
Het komt wel eens voor dat de minimale kardinaliteit groter dan r is. Het attribuut 
SPELER in een object VOETBALELFTAL kan een minimumkardinaliteit van 8 heb- 
ben, omdat een elftal met minder dan acht spelers niet op het veld mag verschijnen. 

De maximumkardinaliteit geeft aan hoeveel instanties van het attribuut het ob- 
ject maximaal mag hebben en is meestal 1 of N. Als het r is, kan het attribuut maar 
één waarde hebben. Met een maximumkardinaliteit van N is het aantal mogelijke 
waarden veel, zonder dat wordt aangegeven hoeveel precies. Soms is de maximum- 
kardinaliteit gelijk aan een bepaald getal, bijvoorbeeld 5, wat betekent dat het object 
niet meer dan vijf instanties van het attribuut mag bevatten. Het attribuut SPELER 
in VOETBALELFTAL kan bijvoorbeeld een maximumkardinaliteit van 16 hebben, 
wat aangeeft dat er maximaal zestien spelers aan een team kunnen worden toegewe- 
zen (elf in het veld en vijf op de reservebank). 

Kardinaliteiten worden afgebeeld als subscripts van attributen in het formaat 
n.m, waarbij n de minimumkardinaliteit is en m de maximumkardinaliteit. In Fi- 
guur E-2(b) zijn zowel de minimum- als maximumkardinaliteit van Vakgroepnaam 
gelijk aan 1. Dit betekent dat er precies één waarde van Vakgroepnaam is vereist. 
De kardinaliteit van Telefoonnummer is gelijk aan 1.N, wat erop duidt dat een VAK- 
GROEP ten minste één telefoonnummer moet hebben, maar dat dat er wel meer 
kunnen zijn. De kardinaliteit van o.1 in Faxnummer betekent dat niet elke VAK- 
GROEP de beschikking over een fax heeft en dat de vakgroepen die er wel een heb- 
ben, niet meer dan één fax hebben. 

De kardinaliteiten van groepen en de attributen in groepen kunnen soms voor 
problemen zorgen. Neem bijvoorbeeld het attribuut Vakgroepadres. De kardinali- 
teiten ervan zijn o.1, wat betekent dat een VAKGROEP niet per se een adres hoeft 
te hebben en dat het maximaal één adres kan hebben. Gebouw en Kantoornum- 
mer zijn attributen van Vakgroepadres en hebben de kardinaliteiten 1.1. Je vraagt je 
misschien af hoe een groep optioneel kan zijn als de attributen in die groep vereist 
zijn. Het antwoord daarop is dat de kardinaliteiten alleen werkzaam zijn tussen het 
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attribuut en de container van dat attribuut. De minimumkardinaliteit van Vakgroep- 
adres geeft aan dat een waarde voor adres in VAKGROEP niet verplicht is. Maar de 
minimumkardinaliteiten van Gebouw en Kantoornummer duiden erop dat deze bei- 
de moeten voorkomen in Vakgroepadres. Een Vakgroepadres-groep is dus niet ver- 
plicht, maar als er een is, moeten Gebouw en Kantoornummer een waarde hebben. 


Objectinstanties 

De objectdiagrammen voor VAKGROEP uit Figuur E-2 kennen een algemene struc- 
tuur die voor elke vakgroep kan worden gehanteerd. In Figuur E-3 zie je een instan- 
tie van het object VAKGROEP met bijbehorende attribuutwaarden voor die bepaalde 
vakgroep. Het betreft hier de vakgroep met de Vakgroepnaam Informatiesystemen, 
die is gelokaliseerd in Kamer 213 van het gebouw voor Sociale Wetenschappen. Merk 
op dat er drie waarden zijn voor Telefoonnummer — de vakgroep Informatiesyste- 
men heeft drie telefoonaansluitingen. Andere afdelingen kunnen er meer of minder 
hebben, maar elke afdeling heeft er minstens één. 


Informatiesystemen Vakgroepnaam 


Sociale Wetenschappen Vakaroepadies 
213 if ir 


491-0099 


491-1182 Telefoonnummer 
491-0098 


493-0100 Faxnummer 
FACULTEIT 


PROFESSORen 


STUDEN Ten 


Figuur E-3 Een instantie van het object VAKGROEP uit Figuur E-2 


Verder is er één instantie van FACULTEIT, de Economische Faculteit, en zijn er 
natuurlijk diverse waarden voor de objectattributen PROFESSOR en STUDENT. 
Professoren en studenten zijn op zichzelf volledige objecten met bijbehorende at- 
tributen, maar om dit diagram eenvoudig te houden, laten we die attributen hier 
onvermeld. 

Een objectdiagram is een schematische voorstelling van het beeld dat een gebrui- 
ker in gedachten heeft over een object in zijn werkomgeving. In het hoofd van de 
gebruiker maken al deze gegevens deel uit van het object VAKGROEP. Een VAK- 
GROEP bevat logischerwijs gegevens over de FACULTEIT waarvan het onderdeel is 
en over de PROFESSORen en STUDENTen die er lesgeven en studeren. 
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Paarsgewijze attributen 


Relaties binnen het semantische objectmodel werken altijd in meer dan één rich- 
ting. Als een object een ander object bevat, bevat dat tweede object tevens het eerste. 
Bijvoorbeeld, als VAKGROEP het objectattribuut FACULTEIT bevat, bevat FACUL- 
TEIT ook VAKGROEP als objectattribuut. Dit soort objectattributen duiden we aan 
met het begrip paarsgewijze attributen, omdat ze altijd als een paar voorkomen. 
Maar waarom moeten objecten nu paren vormen? Het antwoord zit in de manier 
waarop mensen relaties zien. Als object A een relatie heeft met object B, heeft object 
B automatisch een relatie met object A. B is op zijn minst aan A gerelateerd via de 
relatie van ‘dingen die aan B zijn gerelateerd’. Mocht dat argument je vergezocht lij- 


ken, probeer dan eens je een éénrichtingrelatie tussen twee objecten voor te stellen. 
Dat gaat domweg niet. 


E1.3 Object-identifiers 


Een object-identifier bestaat uit een of meer objectattributen die worden gebruikt 
om objectinstanties te identificeren. Zulke identifiers zijn potentiële namen voor 
een semantisch object. Mogelijke identifiers in KLANT zijn bijvoorbeeld KlantID en 
Klantnaam. Dat zijn attributen die gebruikers als geldige namen zien van instanties 
van KLANT. Vergelijk deze identifiers met attributen zoals Besteldatum, Stukprijs 
en Aantal Werknemers. De laatste groep attributen zijn geen identifiers omdat de ge- 
bruikers ze niet als namen van instanties van KLANT zien. 

Een groep-identifier is een identifier met meer dan één attribuut. Voorbeelden 
zijn (Voornaam, Achternaam} en {Voornaam, Telefoonnummer}. 

Object-identifiers kunnen al dan niet uniek zijn, afhankelijk van hoe de gebrui- 
kers hun gegevens zien. Factuurnummer is een voorbeeld van een unieke identifier 
voor ORDER, maar Studentnaam is geen unieke identifier voor STUDENT. Er kun- 
nen meer studenten met dezelfde naam rondlopen. Als er bijvoorbeeld twee stu- 
denten zijn met de naam ‘Stefan Veenendaal’, zullen de gebruikers Studentnaam 
gebruiken voor het identificeren van een groep van een of meer studenten en zullen 
ze zo nodig waarden van andere attributen gebruiken om een bepaald lid van die 
groep te identificeren. 

In semantische objectdiagrammen worden object-identifiers aangeduid met de 
letters ID vóór het attribuut. Als de identifier uniek is, worden deze letters onder- 
streept. In Figuur E-2(b) is het attribuut Vakgroepnaam een unieke identifier van 
VAKGROEP. 

Als een attribuut wordt gebruikt als identifier, is het gewoonlijk verplicht er een 
waarde aan toe te kennen. In het algemeen heeft een identifier-attribuut voor een be- 
paald object niet meer dan één waarde. Daarom is de kardinaliteit van een ID-attri- 
buut meestal gelijk aan 1.1 — die waarde hanteren we dan ook als standaard. 

Het kan echter (in zeldzame gevallen) voorkomen dat de kardinaliteit van een 
identifier anders is dan r.r. Kijk bijvoorbeeld eens naar het attribuut Alias in het se- 
mantische object PERSOON. Een persoon hoeft niet per se een alias te hebben, maar 


kan er net zo goed verscheidene hebben. Vandaar dat de kardinaliteit van Alias o.N 
is. 
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Het weergeven van de subscripts van alle attributen maakt het semantische object- 
diagram rommelig. We vereenvoudigen het diagram daarom door aan te nemen dat 
de kardinaliteiten van identifierattributen met één waarde 1.1 zijn en dat de kardi- 
naliteiten van andere attributen met één waarde o.1 zijn. Mocht de kardinaliteit van 
een attribuut met één waarde daarvan afwijken, dan zullen we dat in het diagram 
vermelden. De subscripts van attributen met één waarde zullen in alle andere geval- 
len worden weggelaten. 


E1.4 _Attribuutdomeinen 

Het domein van een attribuut is de beschrijving van de mogelijke waarden van een 
attribuut. De kenmerken van een domein hangen af van het soort attribuut. Het do- 
mein van een enkelvoudig attribuut bestaat uit een fysieke en een semantische be- 
schrijving. De fysieke beschrijving bevat het datatype (bijvoorbeeld numeriek versus 
string), de lengte van het veld en eventuele andere beperkingen (zoals beginnend 
met een letter of kleiner dan 9999,99). De semantische beschrijving heeft betrek- 
king op de functie of het doel van het attribuut en zorgt voor een onderscheid tussen 
dit attribuut en andere attributen met dezelfde fysieke beschrijving. 

Het domein van Vakgroepnaam kan bijvoorbeeld worden gedefinieerd als ‘de ver- 
zameling strings van maximaal zeven tekens die namen van vakgroepen binnen de 
universiteit van Leiderhoven voorstellen’. In dat geval is het deel ‘strings van maxi- 
maal zeven tekens’ de fysieke beschrijving van het domein en ‘die namen van vakgroe- 
pen binnen de universiteit van Leiderhoven voorstellen’ de semantische omschrijving. 
De semantische beschrijving maakt onderscheid tussen strings van maximaal zeven 
tekens die namen van vakgroepen voorstellen en strings met eenzelfde lengte die 
bijvoorbeeld namen van studierichtingen of gebouwen voorstellen. 

De fysieke beschrijving van het domein van een enkelvoudig attribuut kan ook 
een enumeration zijn. Dit is een opsomming van specifieke waarden van een attri- 
buut. Het domein van het attribuut Onderdeelkleur kan bijvoorbeeld worden weer- 
gegeven als de enumeration {‘Blauw’, ‘Geel’, ‘Rood'}. 

Ook het domein van een groepsattribuut kent een fysiek en een semantisch deel. 
De fysieke beschrijving is een lijst met alle attributen in de groep en de volgorde van 
die attributen. De semantische beschrijving is de functie of het doel van die groep. 
De fysieke domeinbeschrijving van Vakgroepadres in Figuur E-2 is de lijst (Gebouw, 
Kantoornummer} en de semantische beschrijving is ‘de locatie van een kantoor in de 
universiteit van Leiderhoven’. 

Het domein van een objectattribuut is de reeks objectinstanties van dat type. In 
Figuur E-2 is het domein van het objectattribuut PROFESSOR bijvoorbeeld de ver- 
zameling van alle PROFESSOR-objectinstanties in de database. Het domein van het 
object FACULTEIT is de verzameling van alle FACULTEITen in de database. In ze- 
ker opzicht is het domein van een objectattribuut een dynamische enumeration — de 

lijst bevat alle objectinstanties van een bepaald type. 
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VAKGROEP 


Studentenoverzicht 
ID Vakgroepnaam 


ui Vakgroepnaam 


Vakgroepadres 


Gebouw, ; 
Kantoornummer A 


Telefoonnummer , „ 


Faxnummer 


Figuur E-4 Studentenoverzicht en stafoverzicht van het semantische object VAKGROEP 


E1.5 Semantische objectviews 

Gebruikers benaderen de waarden van objectattributen via databaseapplicaties die 
invoerformulieren, rapporten en query’s leveren. Meestal hebben dat soort formulie- 
ren, rapporten en query’s geen toegang nodig tot alle attributen van een bepaald ob- 
ject. In Figuur E-4 zie je twee applicaties die elk het VAKGROEP-object benaderen. 
Sommige attributen van VAKGROEP, zoals Vakgroepnaam, zijn in beide applicaties 
zichtbaar, terwijl andere attributen slechts in een applicatie zijn te zien. STUDENT is 
bijvoorbeeld alleen zichtbaar voor de applicatie Studentenoverzicht, terwijl PROFES- 
SOR alleen bij Stafoverzicht is te zien. 

Het deel van een object dat zichtbaar is voor een bepaalde applicatie noemt men 
de semantische objectview of kortweg view. Een view bestaat uit de naam van het ob- 
ject en een lijst met alle attributen die vanuit die view zijn te zien. Views worden op 
twee manieren gebruikt. Als je een database ontwikkelt, kun je ze gebruiken om het 
datamodel op te zetten. Blader nog eens terug naar Figuur E-1. We hebben al eerder 
laten zien dat ontwikkelaars van de database en de applicatie al terugwerkend het da- 
tamodel proberen af te leiden. Dat houdt in dat ze beginnen bij de formulieren, rap- 
porten en query’s die gebruikers zeggen nodig te hebben en vervolgens terugwerken 
naar het databaseontwerp. Hiertoe selecteert het team een vereist formulier, vereist 
rapport of vereiste query en bepaalt welke views er moeten bestaan om dat formulier, 
dat rapport of die query te realiseren. Vervolgens selecteert men het volgende formu- 
lier, het volgende rapport of de volgende query en volgt dezelfde procedure, waarna 
deze twee views worden gecombineerd. Dit proces wordt herhaald totdat de struc: 
tuur van de gehele database af is. 

De tweede manier waarop views worden gebruikt, treedt op nadat de database- 
structuur is vastgesteld. Dan worden er namelijk views geconstrueerd om nieuwe 
formulieren, rapporten en query’s te maken op basis van de bestaande database- 
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structuur. Voorbeelden van deze tweede applicatie vind je terug in hoofdstuk ro en 
Ir, waarin we SQL Server en Oracle hebben besproken. 


E2 Typen objecten 


In deze paragraaf komen zeven objecttypen ter sprake. Voor elk type bekijken we 
een rapport of formulier en laten we zien hoe we dat rapport of formulier met een 
object modelleren. We transformeren elk van deze typen objecten daarna in een 
databaseontwerp. 

Je maakt in dit deel kennis met drie nieuwe begrippen. Een enkelwaardig at- 
tribuut is een attribuut met een maximumkardinaliteit van 1. Een meerwaardig at- 
tribuut is een attribuut waarvan de maximumkardinaliteit groter dan 1 is. En een 
niet-objectattribuut is een enkelvoudig attribuut of een groepsattribuut. 


INVENTARISLABEL: 
Inventarisnummer: 100 Omschrijving: Bureau 
Aankoopdatum: 27/2/2000 Aankoopprijs: €350,00 


MATERIAAL 
ID Onderdeelnummer 
Omschrijving 


Aankoopdatum 
Aankoopprijs 


INVENTARISLABEL: (b) 
Inventarisnummer: 200 Omschrijving: Lamp 
Aankoopdatum: 3/1/2000 Aankoopprijs: €39,95 


(a) 
MATERIAAL ( Onderdeelnummer , Omschrijving, Aankoopdatum, Aankoopprijs) 
(c) 


Figuur E-5 Voorbeeld van een enkelvoudig object: (a) rapporten gebaseerd op een enkelvoudig object, (b) het 
enkelvoudige object MATERIAAL en (c) een relatie die MATERIAAL representeert 


E2.1 Enkelvoudige objecten 

Een enkelvoudig object is een semantisch object dat alleen enkelwaardige, enkel- 
voudige of groepattributen bevat. In Figuur E-15 zie je een voorbeeld. Er zijn twee 
instanties van het rapport Inventarislabel. Zulke labels zijn bedoeld om bij te houden 
waaruit de kantoorinventaris bestaat en kunnen worden beschouwd als een rapport. 

Figuur E-s5(b) is een voorbeeld van een enkelvoudig object, MATERIAAL, dat In- 
ventarislabel modelleert. De attributen van het object omvatten de items die je in 
het label zag: Onderdeelnummer, Omschrijving, Aankoopdatum en Aankoopprijs. 
Merk op dat geen van deze attributen meerwaardig is en dat geen ervan een object- 
attribuut is. MATERIAAL is dus een enkelvoudig object. 

Figuur E-s(b) is een voorbeeld van een enkelvoudig object, MATERIAAL, dat door 
één relatie kan worden vertegenwoordigd (Figuur E-5(c)). Elk attribuut van het object 
wordt gedefinieerd als een attribuut van de relatie en het identificerende attribuut, 
Onderdeelnummer, is het sleutelattribuut van de relatie, wat wordt aangegeven door 


de onderstreping van dat woord in Figuur E-5(c). 
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In Figuur E-6 is het algemene transformatieschema voor enkelvoudige objecten 
weergegeven. Object OBJECT1 wordt getransformeerd naar relatie Rr. Het attribuut 
dat OBJECTr-instanties identificeert, is Or — dat attribuut wordt de sleutel van relatie 
Rr. Niet-sleutelgegevens geven we hier en in volgende figuren aan met puntjes (…). 
Omdat een sleutel een attribuut is dat een unieke identificatie is voor een rij van 
een tabel, kunnen alleen unieke identifiers — identifiers waarvan de ID is onder- 
streept — naar sleutels worden omgezet. Als het object geen unieke identifier kent, 


moet er een worden gemaakt door de bestaande attributen te combineren of door 
een surrogaatsleutel te definiëren. 


E2.2 Samengestelde objecten 

Een samengesteld object is een semantisch object dat een of meer meerwaardige, 
enkelvoudige of groepattributen bevat, maar geen objectattributen. De hotelreke- 
ning in Figuur E-7(a) toont de noodzaak van een samengesteld object. De rekening 
bevat gegevens die de rekening als geheel aangaan: Rekeningnummer, Aankomst- 
datum, Klantnaam en TotaalVerschuldigd. Verder staat er een reeks attributen op die 
steeds terugkomen en betrekking hebben op diensten die aan de gast zijn verleend. 
Elke groep bevat de attributen Dienstdatum, Dienstomschrijving en Bedrag. 


R1 
Es 


Figuur E-6 Algemeen transformatieschema voor een enkelvoudig object in een relatie 


OBJECT1 
io O1 


Figuur E-7(b) toont een objectdiagram voor het object HOTELREKENING. Het at- 
tribuut Rekeningregel is een groepsattribuut met een maximumkardinaliteit van N, 
wat betekent dat de groep {Dienstdatum, Dienstomschrijving, Bedrag} vele malen 
kan voorkomen in een instantie van het semantische object HOTELREKENING. 
Rekeningregel wordt niet weergegeven als een onafhankelijk semantisch object, 
maar als een attribuut binnen een HOTELREKENING. Deze opzet is juist omdat 
men in het hotel één bepaalde regel van de rekening niet als iets aparts beschouwd, 
zodat rekeningregels niet elk afzonderlijk een identifier hoeven te hebben. Reke- 
ningregels treden alleen op in combinatie met een rekening. Een hotelmedewerker 
voert altijd eerst een rekeningnummer in en dan pas het bedrag dat verschuldigd is. 
Of hij vraagt een bestaande rekening op en voert extra bedragen toe aan die rekening. 
De minimumkardinaliteit van Rekeningregel is o. Dit betekent dat een object 
HOTELREKENING kan bestaan zonder dat er gegevens in Rekeningregel zijn in- 
gevoerd. Hierdoor kan er een rekening worden geopend als de klant zich inschrijft 
en voordat er kosten in rekening zijn gebracht. Als de minimumkardinaliteit 1 zou 
zijn, kon een HOTELREKENING pas worden geopend als er een bepaalde dienst 
aan de klant was verleend. Dit ontwerpbesluit moet plaatsvinden in het licht van de 
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HOTEL ZEEZICHT 
Pall 26, Zandbergen HOTELREKENING 
ID Rekeningnummer 
Rekeningnummer: 1234 Aankomstdatum: 10/12/2001 Aankomstdatum, , 
Klantnaam: Sabine Kooistra ID Klantnaam 


Rekeninaregel 
Dienstdatum, , 
12/10/2001 Kamer € 99.00 Dienstomschrijving, , 
12/10/2001 Maaltijd € 37.55 Bedrag ; 
12/10/2001 Telefoon € 2.50 
12/10/2001 Belasting € 15.00 TotaalVerschuldigd, ; 


13/10/2001 Kamer € 99.00 % 
13/10/2001 Maaltijd € 47.50 (b) 
13/10/2001 Belasting € 15.00 


Totaal verschuldigd € 305.95 


HOTELREKENING ( Rekeningnummer, Aankomstdatum, Klantnaam, TotaalVerschuldigd) 
REKENINGREGEL ( Rekeningnummer, Dienstdaturn, Dienstomschrijving, Bedrag) 
DAGREKENING ( Rekeningnummer, Rekeningdatum, Kamerhuur, Maaltijden, Telefoongebruik, Diversen, Belasting) 


Referential integrity constraints: 
Rekeningnummer in REKENINGREGEL moet bestaan in Rekeningnummer in HOTELREKENING 
Rekeningnummer in DAGREKENING moet bestaan in Rekeningnummer in HOTELREKENING 


(c) 


Figuur E-7 Voorbeeld van een samengesteld object: (a) rapport gebaseerd op een samengesteld object, (b) 
samengesteld object en (c) relationele representatie 


verwerkingsregels. Het kan zijn dat het hotelbeleid is pas een rekening te openen als 
de klant een dienst heeft genoten. In dat geval moet de minimumkardinaliteit van 
Rekeningregel 1 zijn. 

Voor het representeren van dit object creëren we een relatie voor het basisobject, 
HOTELREKENING, en een relatie DAGREKENING voor het steeds terugkerende 
groepsattribuut DagelijkseKosten. Dit relationele ontwerp staat in Figuur E-7(c). 
Rekeningnummer is onderstreept en cursief weergegeven in de sleutel van DAGRE- 
KENING — onderstreept omdat dit attribuut onderdeel is van de sleutel van DAG- 
REKENING en cursief omdat het tevens een externe sleutel is (het is een sleutel van 
HOTELREKENING). Rekeningdatum is onderstreept omdat het onderdeel is van 
de sleutel van DAGREKENING, maar niet cursief omdat het geen externe sleutel is. 

In het algemeen geldt dat samengestelde objecten worden getransformeerd door 
een relatie voor het object zelf te definiëren en een relatie voor elk meerwaardig attri- 
buut. In Figuur E-8(a) bevat object OBJECT: twee groepen meerwaardige attributen, 
die elk worden vertegenwoordigd door een relatie in het databaseontwerp. De sleutel 
van elk van deze tabellen is de samenstelling van de identifier van het object plus de 
identifier van de groep. OBJECTr1 wordt dus voorgesteld door een relatie Rr met sleu- 
tel Or, een relatie R2 met sleutel (Or, Gr) en een relatie R3 met sleutel (Or, Gz2). 

De minimumkardinaliteit van het object naar de groep wordt bepaald door 
de minimumkardinaliteit van het groepsattribuut. In Figuur E-8(a) is de mini- 
mumkardinaliteit van Groep: gelijk aan 1 en die van Groepa2 gelijk aan o. In het 
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OBJECT1 
ID O1 


Groep1 
ID G1 


Groep? 


ID G2 


Referential integrity constraints: 


O1 in R2 moet bestaan in O1 in R1 
O1 in R3 moet bestaan in O1 in R1 


(a) 


OBJECT1 
ID O1 


Groep1 = 
ID G1 


Group2 
ID G2 


R3 iS 
eel) 


Referential integrity constraints: 
O1 in R2 moet bestaan in O1 in R1 
(O1, G1) in R3 moet bestaan in (O1, G1) in R2 
(b) 


Figuur E-8 Algemeen transformatieschema voor samengestelde objecten: (a) samengesteld object met afzon- 
derlijke groepen en (b) samengesteld object met geneste groepen 


datastructuurdiagram zijn deze kardinaliteiten weergegeven als een streepje bij Ra 
en een rondje bij R3. De minimumkardinaliteit van groep naar object is standaard 
altijd r, omdat een groep niet kan bestaan zonder het object dat de groep bevat. Deze 


minimumkardinaliteiten zijn aangegeven door streepjes op de verbindingslijnen 
met Rr. 
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Groepen kunnen genest worden. Figuur E-8(b) toont een object waarin Groepa is ge- 
nest in Groep1. In dergelijke gevallen wordt de relatie die de geneste groep voorstelt 
ondergeschikt gemaakt aan de relatie die de groep representeert. In Figuur E-8(b) is 
relatie R3 ondergeschikt aan relatie Ra. De sleutel van R3 is (Or, Gr, G2) en bestaat 
uit de sleutel (O1, Gr) van Rz2 plus de identifier van Groepa, Ga. 

Je moet ervoor zorgen dat je begrijpt waarom de sleutels in Figuur E-8(b) zijn sa- 
mengesteld op de manier zoals je ze hier ziet. Merk ook op dat sommige attributen 
onderstreept en cursief zijn en dat sommige alleen onderstreept zijn, want sommige 
attributen zijn zowel lokale als externe sleutels, terwijl andere alleen lokale sleutels 
zijn. 


E23 Gemengde objecten 

Een gemengd object bevat minstens één objectattribuut. Figuur E-g(a) toont twee 
verschillende invoerformulieren. Het ene formulier wordt gebruikt om gegevens bij 
te houden over het wagenpark en het andere voor opslag van gegevens over werkne- 
mers. Uit deze formulieren valt op te maken dat een auto aan maximaal één mede- 


werker mag worden toegekend en dat aan een bepaalde medewerker maximaal één 
auto mag worden toegewezen. 


AUTOGEGEVENS 


Kentekennummer Serienummer 
[Merk |Model Bouwjaar 


Medewerkernummer 
Afdeling Telefoon 


Auto toegekend 


MEDEWERKER 
ID Medewerkernaam 
ID Medewerkernummer 
Postadres 
Afdeling 
Telefoon 


AUTO 
ID Kentekennummer 
ID Serienummer 
Merk 
Model 


Bouwjaar 
Kleur 


MEDEWERKER 14 


Looncode 
Functiecode 
DatuminDienst 


AUTO 04 


(b) 


Figuur E-9 Gemengde objecten met 1:1 paarsgewijze eigenschappen: (a) voorbeelden van invoerformulieren 
voor auto's en medewerkers en (b) de samengestelde objecten WERKNEMER en AUTO 
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We kunnen uit de formulieren niet afleiden of een auto moet worden toegewezen 
aan een medewerker en of aan elke medewerker een auto is toegekend. Om daar ach- 
ter te komen, moeten we vragen gaan stellen aan de wagenparkbeheerders en aan 
de mensen bij Personeelszaken. Veronderstel dat blijkt dat een MEDEWERKER niet 
per se een AUTO hoeft te hebben, maar dat een AUTO wel altijd aan een medewer- 
ker moet zijn toegewezen. 

Figuur E-9(b) toont objectdiagrammen voor MEDEWERKER en AUTO. Een ME- 
DEWERKER heeft AUTO als een van zijn attributen en AUTO bevat op zijn beurt 
MEDEWERKER als attribuut. Omdat zowel MEDEWERKER als AUTO objectattri- 
buten bevatten, zijn ze beide gemengde objecten. De relatie tussen MEDEWERKER 
en AUTO is een-op-een (of 1:1), omdat geen van beide attributen meerwaardig is. 

In Figuur E-o(a) bevatten de formulieren Auto en Medewerker elkaar. Dat wil 
zeggen, het formulier Auto heeft een veld Medewerker en het formulier Medewerker 
heeft een veld Auto. Dit is echter niet altijd het geval — soms werkt de relatie maar 
één kant op. In het rapport en formulier in Figuur E-ro(a) zie je twee objecten: STU- 
DENTEN HUIS en STUDENT. Uit het Studentenhuis-Bewonersoverzicht maken we 
op dat volgens gebruikers een studentenhuis attributen heeft van het huis (Huis, Be- 
heerder, Telefoon) en van de studenten (Studentnaam, Studentnummer, Code) die 
in dat huis woonachtig zijn. 

Het formulier Studentgegevens toont echter alleen gegevens over studenten — 
gegevens over het studentenhuis staan er niet in. (Het studieadres kan weliswaar 
het adres zijn van het studentenhuis, maar dit wordt niet belangrijk genoeg geacht 
om in het formulier te vermelden. Als men een database wil gaan ontwikkelen, is 
het wel belangrijk dat deze mogelijkheid wordt besproken met de gebruikers. Wij 
gaan ervan uit dat het formulier met studentgegevens geen gegevens bevat over het 
studentenhuis.) 

Je weet inmiddels dat objectattributen altijd in paren optreden. Zelfs als de for- 
mulieren, rapporten en query’s erop duiden dat slechts één zijde van de relatie zicht- 
baar is, bestaan beide zijden van de relatie. Je kunt het vergelijken met een brug die 
twee eilanden met elkaar verbindt. Beide eilanden zijn met elkaar verbonden, ook al 
geldt er eenrichtingsverkeer. 

Als er geen enkel formulier of rapport kan worden gevonden met gegevens over 
een bepaalde zijde van een relatie, moeten de gebruikers uitsluitsel geven over de 
kardinaliteit van die relatie. In dit voorbeeld moet worden achterhaald hoeveel in- 
stanties van een STUDENTENHUIS een STUDENT kan hebben en of een STU- 
DENT per se in een STUDENTENHUIS moet wonen. We nemen even aan dat uit 
navraag blijkt dat een STUDENT maximaal één STUDENTENHUIS mag bewonen, 
maar eventueel ergens anders woonachtig kan zijn. In Figuur E-ro(b) zie je dat STU- 
DENTENHUIS verscheidene waarden tevat van STUDENT en dat STUDENT één 
waarde van STUDENTENHUIS bevat, zodat de relatie tussen STUDENTENHUIS 
en STUDENT een-op-veel is, of r:N. 

Een derde voorbeeld van gemengde objecten tref je aan in Figuur E-1(a). Uit 
het eerste formulier kunnen we afleiden dat een boek door verscheidene auteurs 
kan worden geschreven en uit het tweede dat een auteur verscheidene boeken kan 
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STUDENTENHUIS-BEWONERSOVERZICHT 
Huis Beheerder Telefoon 


Tolweg Sara Fransen 3-5567 


Studentnaam Studentnummer 
Adams, Elizabeth 

Baker, Regillio 

Baker, Bea 

Karels, Simon 

Schot, Simone 

Tadema, Leo 


B STUDENTGEGEVENS 


Studentnaam [Hakkeldam, Bet 
Studentnummer E45 

Afstudeervak [Werktuigbouwkunde 
Begeleider Pluie Jansens 
Code [Doge 
Vooropleiding [Guiftand College, Baam 


Studieadres lesen 6 


Telefoon [0234-3456 
Record: 1| 4 1 1 p Leu pel van 1 


(a) 


STUDENTENHUIS STUDENT 


ID Huisnaam ID Studentnaam 
ID Beheerder ID Studentnummer 
Telefoon Afstudeervak 


Begeleider 
Code 


STUDENT IN 


EEN 


Vooropleiding 
Studieadres 
Campusadres 
Telefoon 


STUDENTENHUIS 04 


(b) 


Figuur E-10 Gemengde objecten met 1:N paarsgewijze eigenschappen: (a) voorbeeld Studentenhuisrapport 
en Studentgegevensscherm en (b) de gemengde objecten STUDENTENHUIS en STUDENT 
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schrijven. In Figuur E-r1(b) is dat terug te vinden; het object BOEK bevat vele waar- 
den van AUTEUR en AUTEUR bevat vele waarden van BOEK. De relatie tussen 
BOEK en AUTEUR is dus veel-op-veel, of N:M. Verder is het zo dat een BOEK een 
AUTEUR moet hebben en dat een AUTEUR (om zichzelf auteur te kunnen noemen) 
ten minste één BOEK op zijn naam moet hebben staan. De minimumkardinaliteit 
van beide objecten is daarom 1. 

In Figuur E-22 vind je een overzicht van de vier typen gemengde objecten. OB- 
JECT-1 kan een of meer van OBJECT-2 bevatten en omgekeerd kan OBJECT-2 een of 
meer van OBJECT-1 bevatten. Al die relaties hebben betrekking op een vorm van een 
een-op-een-, een-op-veel- of veel-op-veel relatie. De relaties van OBJECT-1 naar OB- 
JECT-2 kunnen specifiek 1:r, 1:N of N:M zijn, terwijl de relaties van OBJECT-2 naar 


OBJECT-1 r:1, :M of M:N kunnen zijn. We kunnen al deze variaties weergeven met 
alleen deze drie typen relaties. 


EB Boekhandel De Boer; voortand 


Java How to Program. 4d Editon 


& Boekhandel De Boer; boeken In voort sad RNR lol x| 
p 


fCarpoet Joseph 
ros 1937 


Auteur 
P [HM Dietel 
PJ Dietel 


+ 

Record: 1} 4 | 1 
ISBN f 30125075 
Uitgever Prentice-Hal 
Datum copyught 1939 


[_|The Hero with a Thousand Faces 123456 
The Inner Reaches of Outer Space 123457» 


Record: U If 1 » [nt raf van 5 


Record: 1 «| 1 _e [orfrel van 1 


BOEK 
o Titel 


AUTEUR 
o Auteursnaam 
Auteursdata 


BOEK ne 


AUTEUR 


wo ISBN 
Uitgeverij 
Datum copyright 


(b) 


Figuur E-11 Gemengde objecten met N:M paarsgewijze eigenschappen: (a) invoerscherm boekhandel en (b) 
de objecten BOEK en AUTEUR 


Object-1 Kan bevatten 


ojee [___ [Een | vee | 
Kan 
Bevatten 


veer | Mat _|_MN | 
eN 


Figuur E-12 Vier typen gemengde objecten 
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E2.4 Gemengde een-op-eenobjecten representeren 
Aan ieder LID van een fitnessclub is een KLUISJE toegewezen. Een KLUISJE wordt 
aan één LID toegekend en elk LID heeft precies één KLUISJE. Figuur E-13(a) toont de 
objectdiagrammen. Als we deze objecten met relaties willen voorstellen, definiëren 
we voor elk object een relatie en plaatsen we, net als bij r:1-entiteitsrelaties, de sleu- 
tel van een van de relaties in de andere relatie. We plaatsen de sleutel van LID dus in 
KLUISJE, of die van KLUISJE in LID. In Figuur E-13(b) is de sleutel van KLUISJE in 
LID geplaatst. Merk op dat Kluisnummer onderstreept is in KLUISJE, omdat het de 
sleutel is, en cursief is in LID, omdat het in die relatie een externe sleutel is. 

In het algemeen definiëren we voor een 1:1-relatie tussen OBJECT1 en OBJECT2 
één relatie per object, bijvoorbeeld Rr en R2. Daarna plaatsen we de sleutel van een 
van beide relaties (O1 of O2) als een externe sleutel in de andere (zie Figuur E-14). 


E2.5 Een-op-veel- en veel-op-veelrelaties representeren 
In Figuur E-15(a) zie je een voorbeeld van een r:N-objectrelatie tussen MATERIEEL 
en REPARATIE. Een instantie van MATERIEEL kan vele instanties van REPARA- 


TIE bevatten, maar een instantie van REPARATIE kan maar aan één instantie van 
MATERIEEL zijn gekoppeld. 


LID KLUISJE 

» Lidnummer » Kluisnummer 
Naam Type 
Adres Combinatie 
Plaats Locatie 
Provincie | 


Postcode 


KLUISJE 
1 


LID (Lidnummer, Naam, Adres, Plaats, Postcode, Kluisnummer) 
KLUISJE (Kluisnummer, Type, Combinatie, Locatie) 
Referential integrity constraints: 

Kluisnummer in LID moet bestaan in 

Kluisnummer in En 


Figuur E-13 Voorbeeld van relationele weergave van gemengde 1:1-objecten: (a) voorbeelden van samenge- 
stelde 1:1-objecten en (b) hun representatie 


De objecten in Figuur E-15(a) worden gerepresenteerd door de relaties in Figuur E- 
15(b). Je ziet dat de sleutel van de parent (het object aan de één-kant van de relatie) is 
geplaatst in de child (het object aan de veel-kant van de relatie). 
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an 


Referential integrity constraint: 


Referential integrity constraint: 


O2 in R1 moet bestaan in O2 in R2 O1 in R2 moet bestaan in O1 in R1 


Figuur E-14 Algemeen transformatieschema voor gemengde 1:1-objecten 


Figuur E-16 toont het algemene transformatieschema voor gemengde r:N-objecten. 
Object OBJECTr bevat vele objecten OBJECT2 en object OBJECT2 bevat slechts één 
OBJECT. We representeren deze structuur doormiddel van relaties door elk object 
als een relatie te representeren en de sleutel van de parent in de child te plaatsen. In 
Figuur E-16 wordt het attribuut Or dus in Ra geplaatst. 

Als OBJECT? veel instanties van OBJECT: bevat en OBJECT: bevat slechts één 
instantie van OBJECT2, hanteren we dezelfde strategie, alleen draaien we de rollen 
van Rr en R2 om en plaatsen O2 dan in Rr. 

De minimumkardinaliteiten worden bepaald door de minimumkardinaliteiten 
van de objectattributen. In Figuur E-16 vereist OBJECT1 minstens één OBJECT2, 
maar OBJECT2 hoeft niet per se over een OBJECT: te beschikken. Deze kardinali- 
teiten zijn in het datastructuurdiagram weergegeven als een rondje aan de Rr-kant 
van de relatie en een streepje aan de R2-kant. Deze waarden voor de minimumkardi- 
naliteit zijn alleen maar voorbeelden — elk van de objecten, of beide, zouden ook een 
kardinaliteit kunnen hebben van o, 1 of een ander getal. 


E2.6 Veel-op-veelrelaties representeren 

Net als bij M:N-relaties tussen entiteiten definiëren we drie relaties, een voor elk 
object en een derde intersectierelatie. De intersectierelatie vertegenwoordigt het ver- 
band tussen de twee objecten en bestaat uit de sleutels van beide parents. Figuur E- 
17(a) toont de M:N-relatie tussen BOEK en AUTEUR. In Figuur E-17(b) staan de drie 
relatietabellen die bij deze objecten horen: BOEK, AUTEUR en BOEK-AUTEUR, de 
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MATERIEEL REPARATIE 
io Serienummer » ID Factuurnummer 
7. Datum 
Omschrijving 
Aankoopdatum Kosten 


Aankoopkosten MATERIEEI 
Locatie 


REPARATIE 


(a) 
MATERIEEL (Serienummer, Type, Model, AankoopDatum, Aankoopkosten, Locatie) 


REPARATIE (Factuurnummer, Datum, Omschrijving, Kosten, Serienummer) 
Referential integrity constraints: 


Serienummer in REPARATIE moet bestaan in 
Serienummer in MATERIEEL 


(b) 


Figuur E-15 Relationele weergave van gemengde 1:N-objecten: (a) voorbeelden van gemengde 1:N-objecten 
en (b) hun representatie 


OBJECT 
O1 


OBJECT2 
io O2 


OBJECT2 
En 


OBJECT1 
0.1 


Referential integrity constraint: 


O1 in R2 moet bestaan in O1 of R1 


Figuur E-16 Algemeen transformatieschema voor gemengde 1:N-objecten 
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intersectierelatie. Je ziet dat BOEK-AUTEUR alleen sleutelgegevens bevat. De attri- 
buten ISBN en SofiNummer zijn onderstreept en cursief omdat ze beide zowel lo- 
kale als externe sleutels zijn. 

Algemeen definiëren we voor twee objecten met een M:N-relatie een relatie Rr 
voor object OBJECTr, een relatie R2 voor object OBJECT2 en een relatie R3 voor 
de intersectietabel. De algemene opzet zie je in Figuur E-18. Je ziet dat R3 alleen de 
sleutels Or en Oz als attributen heeft. Bij gemengde M:N-objecten bevat R3 nooit 
niet-sleutelgegevens. Het belang van deze laatste uitspraak wordt duidelijk als we 
gemengde M:N-relaties gaan vergelijken met associatierelaties. 

Vanwege de minimumkardinaliteit zijn de parents van de intersectierelatie altijd 
vereist. De minimumkardinaliteiten van de relaties in de intersectietabel worden be- 
paald door de minimumkardinaliteiten van de objectlinks. In Figuur E-18 vereist een 
rij in Rr bijvoorbeeld een rij in R3, omdat de minimumkardinaliteit van OBJECT in 
OBJECTr gelijk is aan 1. En een rij in Ra vereist geen rij in R3, omdat de minimum- 
kardinaliteit van OBJECTr in OBJECT2 gelijk is aan o. 


AUTEUR 
io SofiNummer 
Naam 

Telefoon 


BOEK (ISBN, Titel, Code) 


AUTEUR (SofiNummer, Naam, Telefoon) 
BOEK-AUTEUR (/SBN, SofiNummer) 
Referential integrity constraints: 


ISBN in BOEK-AUTEUR moet bestaan in 
ISBN in BOEK 


SofiNummer in BOEK-AUTEUR moet bestaan in 
SofiNummer in AUTEUR 


(b) 


Figuur E-17 Relationele weergave van gemengde N:M-objecten: (a) de objecten BOEK en AUTEUR en (b) hun 
relationele representatie 


E2.7 Hybride objecten 


Hybride objecten zijn combinaties van samengestelde en gemengde objecten. Om 
precies te zijn, een hybride object is een semantisch object met minstens één meer- 
waardig groepsattribuut dat een semantisch objectattribuut bevat. 
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OBJECT1 OBJECT2 
io O1 mo O2 


TN 


Referential integrity constraints: 


O1 in R3 moet bestaan in O1 in R1 
O2 in R3 moet bestaan in O2 in R2 


Figuur E-18 Algemene transformatie van gemengde M:N-objecten naar relatietabellen 


Figuur E-19(a) is een tweede versie van het studentenhuis-bewonersoverzicht in Fi- 
guur E-ro(a). Het verschil is dat de derde kolom van de studentgegevens nu Huur 
bevat in plaats van Code. Dit is een belangrijk verschil omdat huur geen attribuut 
is van STUDENT, maar betrekking heeft op de combinatie van STUDENT en STU- 
DENTENHUIS en een attribuut is van STUDENTENHUIS. 

Figuur E-19(b) toont een objectdiagram dat dit rapport modelleert. STUDENTEN- 
HUIS bevat een meerwaardige groep die bestaat uit het objectattribuut STUDENT 
en het niet-objectattribuut Huur. Dit houdt in dat Huur in de context van STUDEN- 
TENHUIS paarsgewijs voorkomt met STUDENT. 

Kijk nu eens naar het alternatieve STUDENTENHUIS-object in Figuur E-19(c). 
Dit is een onjuist model van het rapport in Figuur E-19(a), omdat het in dit model 
mogelijk is dat Huur en STUDENT onafhankelijk van elkaar verscheidene waarden 
kunnen aannemen — dit is niet mogelijk omdat ze alleen paarsgewijs werken. 

Figuur E-20o(a) toont een formulier dat is gebaseerd op een ander hybride object. 
Dit Verkooporderformulier bevat gegevens over een verkooporder (Verkooporder- 
nummer, Datum, Subtotaal, BTW en Totaal), gegevens over een KLANT en VERKO- 
PER en een meerwaardige groep die gegevens bevat over verkochte artikelen. Verder 
verschijnen er ARTIKEL-gegevens (Artikelnummer, Omschrijving en Stukprijs) bin- 
nen de meerwaardige groep. 

In Figuur E-20(b) zie je het semantische object VERKOOPORDER. Het bevat 
de niet-objectattributen Verkoopordernummer, Datum, Subtotaal, BTW en Totaal en 
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verder de objectattributen KLANT en VERKOPER en een meerwaardige groep die 
staat voor elke regel in de verkooporder. De groep bevat de niet-objectattributen Aan- 
tal en Bedrag en het objectattribuut ARTIKEL. 

De objectdiagrammen in Figuur E-2o(b) zijn in bepaald opzicht voor tweeërlei 
uitleg vatbaar en dit kan afhankelijk van de applicatie wel of niet van belang zijn. 
Volgens het objectdiagram ARTIKEL kan een ARTIKEL worden gekoppeld aan meer 
dan één VERKOOPORDER. Maar omdat de meerwaardige groep Orderregel is inge- 
kapseld in VERKOOPORDER, blijkt uit dit diagram niet of een ARTIKEL een of meer 
keren bij eenzelfde VERKOOPORDER kan optreden. 


STUDENTENHUIS-BEWONERSOVERZICHT 
Huis Beheerder Telefoon 
Tolweg Sara Fransen 3-5567 
Student naam Student Number Huur 
Adams, Elizabeth 710 €175.00 
Baker, Regillio 104 €225.00 
Baker, Bea 744 €175.00 
Karels, Simon 319 €135.00 
Schot, Simone 447 €225.00 
Tadema, Leo 810 €175.00 
Te 
(a) 
E STUDENTENHUTS STUDENT 
wv Huisnaam io Studentnaam 
Beheerder io Studentnummer 
Telefoon 


N Ep STUDENTENHUIS 
Studentnummer 3e 


STUDENT 


(b) 


|C STUDENT 
1 Studentnaam 
ID ‘Studentnummer 


o Huisnaam 
Beheerder 
Telefoon 


7 [STUDENTENHUIS 
STUDENT | 


< 0 


HUrT on d 


Pd (c) EE. 


Figuur E-19 Het hybride object STUDENTENHUIS: (a) bewonersoverzicht met eigenschap Huur, (b) juiste 
STUDENTENHUIS- en STUDENT-objecten en (c) onjuiste STUDENTENHUIS- en STUDENT-objecten 
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In het algemeen kan de maximumkardinaliteit van de paarsgewijze attributen 

in het hybride object VERKOOPORDER op vier verschillende manier worden 

geïnterpreteerd: 

1. Een ARTIKEL kan in slechts één VERKOOPORDER voorkomen en in slechts één 
Orderregel binnen die VERKOOPORDER. 

2. Een ARTIKEL kan in slechts één VERKOOPORDER voorkomen, maar in meer 
Orderregels binnen die VERKOOPORDER. 

3. Een ARTIKEL kan in meer dan één VERKOOPORDER voorkomen, maar in 
slechts één Orderregel binnen die VERKOOPORDERS. 

4. Een ARTIKEL kan in meer dan één VERKOOPORDER voorkomen en in meer 
Orderregels binnen die VERKOOPORDERS. 


Als het van belang is dat er onderscheid wordt gemaakt tussen deze verschillende 
gevallen, moet de volgende notatie worden gebruikt: in geval 1 en 2 moet de maxi- 
mumkardinaliteit van het hybride objectattribuut op 1 worden ingesteld. Voor dit 
voorbeeld houdt dat in dat de maximumkardinaliteit van VERKOOPORDER in AR- 
TIKEL op 1 wordt ingesteld. Als een bepaald ARTIKEL slechts in één Orderregel 
van de VERKOOPORDER voorkomt (geval 1), moet worden aangegeven dat zijn ID 
uniek is in die groep. In geval 2 hoeft dat niet te gebeuren. Deze twee gevallen vind 
je terug in Figuur E-21(a) en (b). 

Als we te maken hebben met geval 3 of 4, stellen we de maximumkardinaliteit 
van het hybride object in op N. Voor dit voorbeeld betekent dat dat de maximumkar- 
dinaliteit van VERKOOPORDER in ARTIKEL op N wordt ingesteld. Als een bepaald 
ARTIKEL slechts in één Orderregel van de VERKOOPORDER voorkomt (geval 3), 
moet worden aangegeven dat zijn ID uniek is in die groep. In geval 4 hoeft dat niet 
te gebeuren — zie Figuur E-21(c) en (d). 


E2.8 Hybride relaties representeren 

Je ziet een algemene beschrijving van de vier genoemde gevallen in Figuur E-22. 
Omdat gevallen 3 en 4 het meeste voorkomen, bespreken we die eerst. OBJECT! 
in Figuur E-23 bevat twee groepen — Groepr geeft een beschrijving van geval 3 en 
Groepa van geval 4. 

Groep: heeft een maximumkardinaliteit van N. Dit betekent dat er veel instanties 
van Groepr binnen een OBJECT: kunnen voorkomen. Er is bovendien aangegeven 
dat OBJECT? ID-uniek is, wat betekent dat een bepaalde instantie van OBJECT2 in 
slechts één van de Groepr-instanties binnen een OBJECT: kan voorkomen. OBJECT2 
gedraagt zich dus als een identifier voor Groepr binnen OBJECT". 

Kijk nu eens naar de relationele voorstelling van Groepr in Figuur E-23. Er wordt 
een relatie Rr gemaakt voor OBJECT1 en een relatie Ra voor OBJECT2. Verder wordt 
er een derde relatie, R-Gr, opgesteld voor Groepr. De relatie tussen Rr en R-Gr is 
r:N — daarom plaatsen we de sleutel Or van Rr in R-Gr. De relatie tussen Ra en R-Gr 
is ook van het type 1:N en dus wordt de sleutel O2 van R2 ook in R-Gr geplaatst. 
OBJECT2 kan bij een bepaalde waarde van OBJECTr maar één keer voorkomen en 
dus is het attributenpaar (Or, O2) uniek in R-Gr en kan als sleutel fungeren. 
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E5 WOUTERS KANTOORMEUDELENVElkoopordergegevens Se lol 
p Ordernummer [ross3 Datum 


Klentnaam Boekhandel De Wijze Uil 


Adres [rt auvestraat 114 
Plaats Berkendal DK En 
Telefoon 023-4545678 


Naam Verkoper [Enret Verkopercode 


78 Directiebureau 
73 Vergadertafel € 1 750,00 
80 Stoel € 93 00 
* 0 0 €000 
Record: «|| 1» [ou [pf van 3 dl 
Subtotaal í € 3.105 0 
BTW 17,5% € 543.38 
Totaal [ € 3.648,33 


Record: [EN K IÍ 1 [mi [pel van 1 


(a) 
VERKOOPORDER ARTIKEL 
wp Verkoopnummer wo Artikelnummer 
Datum Artikelomschrijving 


KLANT k Stukprijs 44 
= amal VERKOOPORDER 
VERKOPER | ae 


Orderregel À 

Aantal 14 | 

ARTIKEL | KLANT 
rr io Klantennaam 

Bedrag 1 Adres 
Subtotaal IN Plaats 
BTW 14 Postcode 
Totaal 44 


Telefoon 


VERKOOPORDER EN 


VERKOPER 
w» Verkopernaam 
Verkopercode 14 


VERKOOPORDER ET 


(b) 


Figuur E-20 Een hybride object VERKOOPORDER en verwante objecten: (a) verkooporderformulier en (b) objec- 
ten die het verkooporderformulier modelleren 
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Kijk nu eens naar Groep2. Groep2 wordt niet geïdentificeerd door OBJECT3. OB- 
JECT3 kan dus in verschillende instanties van Groep2 binnen hetzelfde object 
OBJECT: voorkomen. Omdat OBJECT3 niet de identifier is van Groep2, veronder- 
stellen we dat er een ander attribuut Ga is dat Groepa identificeert. 

In Figuur E-23 is een relatie R3 voor OBJECT3 en een relatie R-G2 voor Groepa 
opgesteld. De relatie tussen Rr en R-Ga is r:N en dus komt de sleutel Or van Rr in 
R-G2. De relatie tussen R3 en R-Gz is ook 1:N en dus komt de sleutel O3 van R3 ook 
in R-G2. 

Het attributenpaar (Or, O3) kan, anders dan bij Groepr, nu echter niet de sleutel 
zijn van R-G2, want een O3 kan veel paren vormen met een gegeven Or. Dat bete- 
kent dat de samenstelling (Or, O3) niet is uniek in R-G2. De sleutel van R-G2 wordt 
daarom (Or, G2). 

Geval 1 is vrijwel gelijk aan geval 3, met dien verstande dat nu een OBJECT 2 maar 
bij één OBJECT: kan horen. De relaties in Figuur E-23 blijven juist, maar we moe- 
ten de sleutel Or van Rr aan Ra toevoegen en als voorwaarde opgeven dat (Or, O2) in 
R-Gr gelijk moet zijn aan (Or, O2) in Ra. 

Geval 2 lijkt veel op geval 4, afgezien van de beperking dat een OBJECT3 maar 
bij één OBJECT: kan horen. De relaties in Figuur E-23 zijn nog steeds correct, maar 
we moeten de sleutel Or van Rr aan R3 toevoegen en opleggen dat (Or, O3) in R-G2 


ARTIKEL VERKOOPORDER 


VERKOOPORDER ARTIKEL 


wo Verkoopordernummer 
Datum 


o Artikelnummer 
Artikelomschrijving 


Stukprijs 


wo Verkoopordernummer 
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wo Artikelnummer 
Artikelomschnjving 


KLANT KLANT SEE 
1 Eri 7 11 ETE p= | 
VERKOPER |, RERKOOROBDE VERKOPER 
Orderregel Ordorregel 
Aantal ‚, Aantal 
aamker |J 
1 11 
Bedrag 14 Bedrag 11 
Subtotaal, , Subtotaal ,, IN 
BTW ‚1 
Totaal , ‚ 


VERKOOPORDER 
1 Verkoopordernummer 
Datum 


KLANT ke 
VERKOPER Ô 
1 


Orderregel 
Aantal ‚, 


of ARTIKEL 
1 


Bedrag 
Subtotaal 
BTW 11 
Totaal 


(c) 


ARTIKEL 
mo ID Artikelnummer 
Artikelomschrijving 


Stukprijs 


VERKOOPORDER ' 


VERKOOPORDER 
w Verkoopordernummer 
Datum 


ar, 
VERKOPER ne 


Orderregel 
Aantal 


ARTIKEL Hd 


Bedrag 1 


Subtotaal , ; 


ARTIKEL 

wo Artikelnummer 
Artikelomschrijving 
Stukprijs 4 + 


VERKOOPORDER| 


Figuur E-21 Voorbeelden van de vier gevallen voor de maximumkardinaliteit in een hybride object: (a) ARTI- 
KEL en één ORDER, (b) ARTIKEL in (mogelijk) veel Rekeningregels van één ORDER, (c) ARTIKEL in één Rekening- 
regel van (mogelijk) veel ORDERS en (d) ARTIKEL in (mogelijk) veel Rekeningregels van (mogelijk) veel ORDERS 
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een deelverzameling is van (O1, O3) in R3 (zie vraag E.21 en E.22 aan het eind van dit 


hoofdstuk). 


[Geval Omschrijving Ì T voorbeeld 

1 OBJECT2 heeft betrekking op ARTIKEL is aan één ORDER 
één instantie van OBJECT1 en _ | gerelateerd en kan in maar één 
verschijnt maar in een groepin- Rekeningregel van die ORDER 
stantie binnen dat object. voorkomen 

2 OBJECT2 heeft betrekking op ARTIKEL is aan één ORDER 


één instantie van OBJECT1 en gerelateerd en kan in 

| kan in verscheidene groepinstan- | verscheidenen Rekeningregels 
| |ties binnen dat object voorkomen} van die ORDER voorkomen 
[3 OBJECT2 kan betrekking hebben | ARTIKEL is aan veel ORDERs 
op verscheidene instanties van _|gerelateerd en kan in maar één 
OBJECT1 en kan in maar één Rekeningregel van die ORDER 
groepinstantie voorkomen binnen | voorkomen 


4 elk object. 

4 OBJECT2 kan betrekking hebben | ARTIKEL is aan veel ORDERs 

| op verscheidene instanties van gerelateerd en kan in 
OBJECT1 en kan voorkomen in verscheidene Rekeningregels van 
verscheidenen groepinstanties die ORDER voorkomen 

| binnen deze objecten. 


Figuur E-22 Vier soorten kardinaliteit bij hybride objecten 


E2.9 Associatieobjecten 

Een associatieobject is een object dat twee (of meer) objecten met elkaar verbindt en 
gegevens opslaat die bij die relatie behoren. Het rapport en twee invoerschermen in 
Figuur E-24(a) geven aanleiding tot de noodzaak van een associatieobject. Het rap- 
port bevat gegevens over een vlucht en over het vliegtuig en de piloot die aan die 
vlucht zijn toegewezen. De twee invoerformulieren bevatten gegevens over een pi- 
loot en een vliegtuig. 

In Figuur E-24(b) is het object VLUCHT een associatieobject dat de twee objecten 
VLIEGTUIG en PILOOT aan elkaar koppelt en gegevens opslaat over die koppeling. 
VLUCHT bevat één VLUCHT en één PILOOT, maar zowel VLIEGTUIG als PILOOT 
bevatten verscheidene waarden van VLUCHT. Dit patroon waarbij twee (of meer) ob- 
jecten worden gekoppeld aan gegevens over de koppeling treedt vaak op, met name 
in applicaties waarbij twee of meer zaken worden toegekend. Andere voorbeelden 
zijn een OPDRACHT die een ARCHITECT met een KLANT verbindt, een TAAK die 
een MEDEWERKER aan een PROJECT koppelt en een AANKOOPORDER die een 
LEVERANCIER met een DIENST verbindt. 

In het voorbeeld in Figuur E-24 heeft het associatieobject VLUCHT een eigen 
identifier, de groep {Vluchtnummer, Datum). Associatieobjecten hebben vaak geen 
eigen identifier en in die gevallen is de identifier de combinatie van de identifiers van 
de geassocieerde objecten. 

Bekijk ter verduidelijking Figuur E-25(a), waarin je een rapport ziet staan van de 
toekenning van architecten aan projecten. De identifier is in dit geval de combinatie 
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OBJECT2 OBJECT3 
io O2 io O3 


OBJECT1 
io O1 


OBJECT1 | OBJECT1 | 


Groep1 


P| OBJECT2 eel 
1 


Groep2 
m G2 Ee Geval 4 


OBJECTS os | 


Referential integrity constraints: 


O1 in R-G1 moet bestaan in O1 in R1 
O2 in R-G1 moet bestaan in O2 in R2 
O1 in R-G2 moet bestaan in O1 in Rí1 
O3 in R-G2 moet bestaan in O3 of R3 


Figuur E-23 Algemene transformatie van hybride objecten naar relaties 


(Projectnaam, Architectnaam}. Deze attributen behoren echter tot PROJECT en 
ARCHITECT en niet tot OPDRACHT. De identifier van OPDRACHT is dus de com- 
binatie van de identifiers van de aan OPDRACHT toegekende dingen. 

Figuur E-25(b) toont de objectdiagrammen voor deze situatie. PROJECT en AR- 
CHITECT zijn beide objectattributen van OPDRACHT en de groep {PROJECT, 
ARCHITECT) is de identifier van OPDRACHT. Dit betekent dat de combinatie van 
een instantie van PROJECT en een instantie van ARCHITECT een bepaalde OP- 
DRACHT identificeert. 

De identifier OpdrachtID in Figuur E-25(b) is overigens niet uniek — dezelfde 
architect kan kennelijk meer dan één keer op een project worden gezet. Als dit in 
werkelijkheid anders is, moet de identifier als uniek worden gekenmerkt. Als een 
werknemer meer dan één keer aan een project kan worden toegewezen en als het 
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c 
FLY CHEAP INTERNATIONAL 
Vluchtplanoverzicht 
VLUCHTNUMMER FC-17 DATUM 7/30/2001 
VERTREKPLAATS Amsterdam BESTEMMING Hongkong 


BRANDSTOF BĲ VERTREK 


GEWICHT BĲ VERTREK 


VLIEGTUIG 
Identificatienummer _N1234F/ 
Type 747-SP 
Capaciteit 148 
PIEOOT een TE 
Naam Michael Nilson 
FCI-ID 32887 


Vlieguren 


B VLIEG VOORDELIG INTERNATIONAAL 


Pilootgegevens 


FCIL_ID [32867 DatumLaatsteContr 7-7-2001 
Naam [Michael Nilson Vlieguen [1848 
Sofi-nummer [1234567839 DatumLaatsteMedOn [____ 1852001 
Adres [weslaan 101 


Plaats Wegendal 


Postcode [2456Ty 
Telefoonnummer 555-6566777 
In noodgeval bellen [£55-577778 


Record: | 4 Ì 1 pr Lei pe] van 1 


& Reserveringen 


Vliegtuiggegevens 


\dentificatienummer [N12324F1 

Merk ÚBobiig err ef 

Type PAISP | 

Vlieguren KEE 

Motoruren EE : 


MotorurenSindslL aats 756 


„Zit 


(a) 


Figuur E-24 Voorbeelden van een associatieobject: (a) vluchtrapport en -formulieren en (b) de objecten 
VLUCHT, PILOOT en VLIEGTUIG 
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VLIEGTUIG PILOOT 

1 Identificatienummer io FCI-ID 
Merk ov Naam 
Type ip Sofi-nr 
Vlieguren Straat 
Motoruren Plaats 


VLUCHT 
1o VluchtiD 
Vluchtnummer! 
Datum 
Vertrekplaats 
Bestemming 


MotorLaatsteControle Postcode 
Capaciteit Telefoon 
Actieradius Telnood 


2E DatumLaatsteControle 
VLUCHT ON Vlieguren 


DatumLMedOnderzoek 


BrandstofBijVertrek 
GewichtBijVertrek 


VLIEGTUIG it 
PILOOT EN 


(b) 


Figuur E-24 (vervolg) 


om wat voor reden dan ook belangrijk is dat er een unieke identifier is voor een OP- 
DRACHT, zal er een attribuut aan de groep moeten worden toegevoegd dat de tijd 
aangeeft, zoals Datum of Weeknummer. 

Algemeen gesteld, als we associatie-objectstructuren in relaties transformeren, 
zullen we een relatie definiëren voor elk van de objecten die aan de relatie deel- 
neemt. In Figuur E-26 koppelt OBJECT3 OBJECT: en OBJECT2 aan elkaar. Vandaar 
dat we de relatietabellen Rr, R2 en R3 definiëren. De sleutels van de parent-relaties, 
Or en O2, verschijnen als externe sleutelattributen in R3, de relatietabel die het as- 
sociatieobject representeert. Als het associatieobject geen attribuut zou hebben dat 
het op unieke wijze identificeert, zou het attributenpaar Rr en R2 worden gebruikt 
als unieke identifier. 

Let op het verschil tussen de associatierelatietabel in Figuur E-26 en de intersec- 
tietabel in Figuur E-18. Het voornaamste onderscheid is dat in de eerstgenoemde 
tabel gegevens staan die iets zeggen over de combinatie van de objecten. De inter- 


sectietabel bevat geen gegevens, maar geeft alleen aan welke objecten een relatie met 
elkaar hebben. 


E2.10 Parent/subtype-objecten 
Het in Figuur E-27(a) weergegeven object MEDEWERKER licht parent- en subtype- 
objecten toe. Sommige van de attributen van MEDEWERKER hebben betrekking op 
alle medewerkers en andere zijn alleen van toepassing op werknemers die de rol van 
manager vervullen. Het object in Figuur E-27(a) is niet erg nauwkeurig, omdat attri- 
buten die betrekking hebben op managers ongeschikt zijn voor gewone werknemers. 
Een beter model is dat in Figuur E-27(b), waarin het object MEDEWERKER een 
subtype-object MANAGER bevat. Alle attributen die betrekking hebben op mana- 
gers zijn verplaatst naar het object MANAGER. Medewerkers die geen manager 
zijn, hebben één objectinstantie MEDEWERKER en geen objectinstanties MANA- 
GER. Werknemers die het tot manager hebben geschopt, hebben zowel een MEDE- 
WERKER-instantie als een MANAGER-instantie. In dit voorbeeld wordt het object 
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Overzicht Projectopdrachten 


Projectnaam: Poorthuis Architect: 
Projectleider: Smit, J. Telefoon: 
Startdatum: 11/11/1999 Kantoor: 
Einddatum: 


Startdatum opdracht: 15/12/2001 
Einddatum opdracht: 15/03/2002 | | 
Maximumaantal gebudgetteerde uren: 345 5 | 
Maximale arbeidskosten: €27.500 
Maximale materiaalkosten: €17.500 


PROJECT 

wo Projectnaam 
Projectleider 
Projectstart 
Projecteind 


OPDRACHT E: 


OPDRACHT 
vo OpdrachtlD 


PROJECT | 
zal 
ARCHITECT | | 


Startopdracht 
Eindopdracht 
MaxUren 
MaxArbeidskosten 
MaxMateriaalkosten 


ARCHITECT 

wo Naam 
Telefoon 
Kantoor 


OPDRACHT ei 


(b) 


Figuur E-25 Het associatieobject OPDRACHT: (a) voorbeeld van opdrachtenrapport en (b) het object OPDRACHT ; 
met semantische object-1D 


MEDEWERKER een parent-object of supertype-object genoemd en het object MA- 
NAGER een subtype-object. 

Het eerste attribuut van een subtype is het parentattribuut dat wordt aangeduid 
met een P. Parentattributen zijn altijd vereist. De identifiers van het subtype zijn ge- 
lijk aan die van de parent. In Figuur E-27(b) zijn Medewerkernummer en Medewer: 
kernaam identifiers van zowel MEDEWERKER als van MANAGER. 

Subtype-attributen worden weergegeven in de notatie o.ST of 1.ST. Het eerste cij- 
fer (o of 1) is de minimumkardinaliteit van het subtype. Als het o is, is het subtype 
optioneel — een 1 geeft aan dat het subtype verplicht is. (Een verplicht subtype is niet 
zinvol in dit voorbeeld, maar zal dat wel zijn in de meer ingewikkelde voorbeelden 
hierna.) De aanduiding ST geeft aan dat het attribuut een subtype ofwel een IS-EEN- 
attribuut is. 
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OBJECT3 
io O3 


OBJECT1 
po O1 


OBJECT 
1 
11 


OBJECTS) 
‚N 


Referential integrity constraints: 
O1 in R3 moet bestaan in O1 in R1 
O2 in R3 moet bestaan in O2 in R2 
Figuur E-26 Algemene transformatie van associatieobjecten naar relaties 


Parent/subtype-objecten hebben een belangrijk kenmerk, dat overerving of inheri- 
tance wordt genoemd. Een subtype verkrijgt of erft alle attributen van zijn parent. 
Daarom erft MANAGER alle attributen van een MEDEWERKER. Omgekeerd erft 
de parent alle attributen van zijn subtypen — een MEDEWERKER die MANAGER is, 
erft alle attributen van MANAGER. 

Een semantisch object kan meer dan één subtype-attribuut bevatten. Figuur E-28 
toont een tweede MEDEWERKER-object met twee subtype-attributen: MANAGER 
en PROGRAMMEUR. Omdat al deze attributen optioneel zijn, kan een MEDEWER- 
KER geen, een of beide subtypen hebben. Een medewerker kan dus manager zijn 
maar geen programmeur, programmeur maar geen manager, programmeur én ma- 
nager of geen van beide. 

Soms sluiten subtypen elkaar uit. Zo kan een VOERTUIG een PERSONENAU- 
TO of een TRUCK zijn, maar niet beide. Een KLANT kan een PERSOON, MAAT- 
SCHAP of NV zijn, maar niet meer dan één van deze drie typen. Als subtypen elkaar 
uitsluiten, worden ze in een subtypegroep geplaatst, waarna aan de groep de code- 
ring X.Y.Z. wordt toegekend. X is de minimumkardinaliteit en is o of 1, afhankelijk 
van of de subtypegroep al dan niet vereist is. Y is het minimale aantal attributen in de 
groep dat een waarde moet hebben en Z staat voor het maximaal toegestane aantal. 
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MEDEWERKER 
io Medewerkernummer, , 
io Medewerkernaam ; + 
DatumInDienst 

Salaris 


Medewerkersgegevens 


Managertitel 
MgmtNiveau 
MgmtBonusVerdiend 
MgmtBonusUitbetaald 


Managergegevens 


(a) 


MEDEWERKER MANAGER 
wMedewerkernummer ERE 
ioMedewerkernaam MEDEWERKER p 


DatuminDienst Managertitel 

Salaris MgmtNiveau 
MANAGER MgmtBonusVerdiend 

MgmtBonusUitbetaald 


(b) 
Figuur E-27 Noodzaak voor een subtype MANAGER: (a) MEDEWERKER zonder subtype, (b) MEDEWERKER met 
subtype MANAGER 


MANAGER 


MEDEWERKER ke 


Managertitel 


MEDEWERKER 

io Medewerkernummer 

w Medewerkernaam 
DatuminDienst 


Salaris 


MANAGER 
o.ST 
PROGRAMMEUR 
0.ST 


MgmtNiveau 
MgmtBonusVerdiend _ | 
MgmtBonusUitbetaald f 


PROGRAMMEUR 


WERKNEMER 5 


Taal on | 
Besturingssysteem ‚‚n 


Figuur E-28 MEDEWERKER met twee subtype-eigenschappen 


In Figuur E-29(a) staan drie typen van KLANT weergegeven als een subtypegroep. 
De notatie 0.1.1 die bij de groep staat, betekent dat het subtype niet verplicht is, maar 
dat als het bestaat, er minimaal één en maximaal één (precies één dus) subtype in de 
groep aanwezig is. Merk op dat elk subtype in dit voorbeeld de codering o.ST heeft, 
wat aangeeft dat ze allemaal optioneel zijn. Zouden ze allemaal vereist zijn, dan zou 
het maximumaantal drie moeten zijn, ín plaats van één. Met deze notatie kan elke 
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situatie worden beschreven, dus ook die waarin bijvoorbeeld drie uit vijf of zeven uit 
tien subtypen vereist zijn. 


PERSOON 


KLANT 5 


SofiNummer 
Evaluatie 


KLANT 

» Klantnummer 

» Klantnaam 
Telefoon 


PERSOON 
0.ST 


| 
MAATSCHAP | 
0.ST 


| 
MAATSCHAP 


KLANT n 


BTW-nummer 
Partner 


N 


V 
KLANT 
P 


BTW-nummer 
Balanstotaal 
Contactnaam 
Contacttelefoon 


ONDERNEMING | | BELASTINGPLICHTIG 


KLANT |, | ONDERNEMING) „ 
BTW-nummer | 
Balanstotaal | 


Contactnaam 
Contacttelefoon 


BEEGElehG | | _NIET-BELASTINGPLICHTIG 
0.ST 4 
NIET-BELASTINGPLICHTIe) … | ONDEENEMING 


Vrijstellingscode 


OVERHEIDSINSTELLING en 
ONDERWIJSINSTELLING oen 
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NIET-BELASTINGPLICHTIG 5 NIET-BELASTINGPLICHTIG 4 


Districtsnaam Instellingscode 


(b) 
Figuur £-29 Exclusieve (a) en geneste (b) subtypen 
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Er kunnen nog ingewikkeldere beperkingen bestaan als subtypen worden genest. 
De subtypegroep in Figuur E-29(b) schetst een situatie waarbij het subtype ONDER- 
NEMING ofwel BELASTINGPLICHTIG is of NIET-BELASTINGPLICHTIG is. Als 
het om een onderneming gaat die niet-belastingplichtig is, moet het gaan om een 
OVERHEIDSINSTELLING of om een ONDERWIJSINSTELLING. In dit voorbeeld 
zijn maar een paar niet-objectattributen afgebeeld. Er zouden in werkelijkheid waar- 
schijnlijk veel meer attributen nodig zijn als een dergelijke, ingewikkelde structuur 
nodig zou zijn. 

In Figuur E-3o zie je een algemeen schema voor het weergeven van subtypen. Er 
wordt een relatie voor de parent gecreëerd en een voor elk subtype. De identifier van 
de parent is de sleutel van elke relatie. Alle relaties tussen de parent en het subtype 
zijn r:1. Let op de horizontale lijn door de verbindingslijnen en de aanwezigheid van 
de kardinaliteit van de subtypegroep. De getoonde waarde, o.1.1, betekent dat er geen 
subtype verplicht is en dat er maximaal één is toegestaan. 


SUBTYPE1 


(omsecri), 


SUBTYPE1 | 
0.ST 


SPES er | SUBTYPE2 


0.1.1 [osvecri}, 


Referential integrity constraints: 


O1 in R2 moet bestaan in O1 in R1 
Oí in R3 moet bestaan in O1 in Rí 


Figuur E-30 Algemene transformatie van parent/subtypeobjecten in relaties 
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E2.11 Archetype/versie-objecten 

Het laatste type object is het archetype/versie-object. Een archetype-object is een se- 
mantisch object dat andere semantische objecten voortbrengt die versies of edities 
van het archetype vertegenwoordigen. In Figuur E-31 produceert het archetype-object 
LEERBOEK de versie-objecten EDITIEs. Volgens dit model horen de attributen Titel, 
Auteur en Uitgever bij het object LEERBOEK en horen de attributen Editienummer, 
Publicatiedatum en AantalPaginas bij de EDITIE van het LEERBOEK. 


LEERBOEK EDITIE 
o ISBN jo EditielD 


Titel 
PEDT: LEERBOEK B 


Uitgever Editienummer 


EDITIE Publicatiedatum 
LN AantalPagina's 


Figuur E-31 Voorbeeld van een archetype /versieobject 


De ID-groep in EDITIE bestaat uit twee onderdelen: LEERBOEK en Editienummer 
— dit is het gebruikelijke patroon voor een ID van een versie-object. Het ene deel van 
de ID bevat het archetype-object en het andere deel is een enkelvoudig attribuut dat 
de versie binnen het archetype aanduidt. Figuur E-32 toont nog een voorbeeld van 
archetype/versie-objecten. Figuur E-33 toont de algemene transformatie van arche- 
type/versie-objecten. Attribuut Or van Ra is zowel een lokale als een externe sleutel, 
maar Oa is alleen een lokale sleutel. 


GEBOUW APPARTEMENT 
io Naam io AppartementiD il 


Adres 3 
Straat | GEBOUW 11 


Postcode 4 
AantalVerdiepingen * 


APPARTEMENT EN 


| 
Plaats il Appartementnummer, 4 | 


AantalSlaapkamer DA 


AantalVierkMtrs 


Figuur E-32 Nog een voorbeeld van een archetype /versieobject 
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OBJECT1 
io O1 


OBJECT2 
> Object2ID 


OBJECT2 


J.N 


| 
R2 id 


O1 02 


Referential integrity constraint: 
O1 in R2 moet bestaan in O1 in R1 


Figuur E-33 Algemene transformatie van archetype /versieobjecten in relaties 


E3 Het semantische objectmodel versus het E-R-model 


Tussen het E-R-model en het semantische objectmodel bestaan bepaalde overeen- 
komsten, maar ook enige verschillen. Beide modellen zijn hulpmiddelen voor het 
begrijpen en documenteren van de structuur van gebruikersgegevens en ze hebben 
beide als taak de structuur vast te leggen van zaken in de gebruikersomgeving en van 
de onderlinge relaties die daarbij een rol spelen. 

Het voornaamste verschil tussen de twee modellen ligt in de gebruikte bouw- 
stenen. Het E-R-model ziet het concept van entiteit als basis. Entiteiten en hun on- 
derlinge relaties worden beschouwd als de bouwstenen van een datamodel. Deze 
bouwstenen kunnen worden gecombineerd tot zogenoemde userviews — dit zijn com- 
binaties van entiteiten waarvan de structuur lijkt op die van semantische objecten. 

Het semantische objectmodel gaat uit van het concept van het semantische object. 
De reeks semantische objecten in een datamodel is een afbeelding van de basis- 
structuur van de dingen die de gebruiker belangrijk vindt. Deze objecten vormen 
de bouwstenen van de gebruikersomgeving en zijn de kleinst mogelijke eenheden 
waarmee de gebruikers willen werken. Ze kunnen worden ontleed in kleinere delen 
binnen het DBMS (of de applicatie), maar die kleinere delen hebben voor de gebrui- 
kers geen nut. 

Volgens het semantische objectmodel bestaan er geen entiteiten zoals die in het 
E-R-model worden gedefinieerd. Dat zijn slechts stukken van de werkelijke entitei- 
ten. De enige entiteiten die voor gebruikers iets betekenen, zijn semantische objec 
ten. Een andere manier om dit uit te drukken, is door te zeggen dat de semantische 
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objecten semantisch onafhankelijk of semantisch compleet zijn. We gaan ter verduide- 
lijking hiervan eens kijken naar een voorbeeld in Figuur E-33 waar vier semantische 
objecten zijn afgebeeld: VERKOOPORDER, KLANT, VERKOPER en ARTIKEL. Als 
een bepaalde gebruiker zegt: ‘Ik wil graag verkoopordernummer 2000 zien’, dan 
wil hij of zij VERKOOPORDER zien zoals deze is gemodelleerd in Figuur E-34. Dat 
omvat, naast andere attributen, KLANT-gegevens. Omdat KLANT onderdeel is van 
VERKOOPORDER, bevat het object VERKOOPORDER het object KLANT. 

Figuur E-35 is een E-R-model van dezelfde gegevens en bevat de entiteiten VER- 
KOOPORDER, KLANT, VERKOPER, ORDERREGEL en ARTIKEL. De entiteit VER- 
KOOPORDER kent de attributen Ordernummer, Datum, Subtotaal, BTW en Totaal. 
Als een gebruiker nu zou zeggen: ‘Toon me verkoopordernummer 2000’, en hij of 
zij zou alleen de attributen Datum, Subtotaal, BTW en Totaal te zien zou krijgen, zou 
de gebruiker zeer teleurgesteld zijn. De gebruiker zal waarschijnlijk vragen waar de 
rest van de gegevens is gebleven. De entiteit VERKOOPORDER is dus geen goede 
weergave van de betekenis die de gebruiker geeft aan de aparte identiteit VERKOOP- 
ORDER. De entiteit is maar een deel van VERKOOPORDER. 


VERKOOPORDER KLANT 
» Ordernummer » Klantnummer 
Datum » Klantnaam 


ZT ANT Adres 
KLANT nt Straat | 
VERKOPER | Beats 


Orderregel 


1.1 
À 
Aantal | VERKOOPORDER pf 
| 
| 


Postcode 


Bedrag 
Subtotaal 
BTW ARTIKEL 
Totaal » Artikelnummer 

Naam 
Omschrijving 


VERKOOPORDER BN 


iN 


VERKOPER 
1D Verkopernaam 
» Verkopercode 


VERKOOPORDER zal 


Figuur E-34 VERKOOPORDER en gerelateerde semantische objecten 


Als een gebruiker zegt: ‘Ik wil klant 12345 zien’, wil hij of zij graag alle gegevens 
zien die zijn gemodelleerd voor KLANT in Figuur E-34, inclusief Klantnaam, alle at- 
tributen van de groep Adres en alle VERKOOPORDERs voor die KLANT. De entiteit 
KLANT in Figuur E-35 heeft alleen de attributen Klantnaam, Straat, Plaats en Post- 
code. Als de gebruiker zou zeggen: “Toon me klant ABC’, en zou hij of zij alleen deze 
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gegevens krijgen toegeschoven. dan zou de gebruiker opnieuw teleurgesed 7e en 
zeggen: ‘Er ontbreekt volgens mij nog wat.’ 

Volgens het semantische objectmodel zijn E-R-entiteiten niet negiig ‘perars aee 
objecten kunnen eenvoudig worden omgezet in databascontwergen, rad der en 
ten uit het E-R-model. Het zijn in feite constructies die ergens lig gen tussen hes sne 
del van datastructuren en het model dat de gebruiker voor ogen eef 

Een ander verschil is dat de semantische objecten meer metadarz ergeren dar 4e 
entiteiten. In Figuur E-34 legt het semantische objectmodel vast das wignengennner 
in de ek van 1de gebruiker een ee EERE is. Het kan 4! en weten 


meer dan één VERKOOPORDER kan zijn gekoppeld, maar dat het : 
Orderregel binnen die VERKOOPORDER in verband kan staan. Dit f 
worden weergegeven in het E-R-diagram. 

Het is aan jou te bepalen of Figuur E-34 of Figuur E-35 je een beter idee geen van 
wat er in de database zou moeten staan. Veel mensen vinden dat de kaders zoz de 
semantische objecten en de haakjes rond de groepsattributen hen een beter over 
zicht geven van het datamodel. 


Herhalingsvragen 


Er In welk opzicht kan men het E-R-model en het semantische objecumodel ver 
gelijken met lenzen van een vergrootglas? 
E2 Definieer het begrip semantisch object. 
E3 Wat is het verschil tussen de naam van een objectklasse en die van een oDsec 
instantie? Geef van elk een voorbeeld. 
E4 Wanneer is de beschrijving van een verzameling attributen voldoende ce 
noemen? 
Es Wat bedoelt men met het begrip aparte identiteit in de definitie van een semar- 
tisch object? 
E6 Verklaar waarom een orderregel binnen een order geen semantisch obiect is. 
E7 Wat zijn de drie typen attributen? 
E8 Geef een voorbeeld van: 
„ een enkelvoudig enkelwaardig attribuut 
een enkelwaardig groepsattribuut 
„ een enkelvoudig meerwaardig attribuut 
„ een meerwaardig groepsattribuut 
een enkelvoudig objectattribuut 
een meerwaardig objectattribuut 


HGO 
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E.g9 Wat is minimumkardinaliteit en hoe wordt deze gebruikt? Welke soorten attri- 
buten hebben een minimumkardinaliteit? 

E.ro Wat is maximumkardinaliteit en hoe wordt deze gebruikt? Welke soorten attri- 
buten hebben een maximumkardinaliteit? 

E.1rr Wat zijn paarsgewijze attributen en waarvoor zijn deze nodig? 

E.12 Watiseen object-identifier? Geef een voorbeeld van een enkelvoudige attribuut- 
object-identifier en een voorbeeld van een groepsattribuut-object-identifier. 

E.13 Geef een definitie van het begrip attribuutdomein. Welke typen attribuutdomei- 
nen bestaan er? Waarom is een semantische beschrijving noodzakelijk? 

E.14 Wat is een semantische objectview? Bedenk zelf een voorbeeld van een object 
en twee views. 

E.rs Bedenk zelf een voorbeeld van een enkelvoudig object. Laat zien hoe dat object 
wordt weergegeven met relaties. 

E16 Bedenk zelf een voorbeeld van een samengesteld object. Laat zien hoe dat ob- 
ject wordt weergegeven door middel van relaties. 

E17 Bedenk zelf een voorbeeld van een 1:1 samengesteld object. Noem twee manie- 
ren waarop dit object kan worden weergegeven met relaties. 

E18 Bedenk zelf een voorbeeld van een r:N samengesteld object. Laat zien hoe dat 
object wordt weergegeven met relaties. 

E.1g Bedenk zelf een voorbeeld van een M:1 samengesteld object. Laat zien hoe dat 
object wordt weergegeven met relaties. 

E.20 Bedenk zelf een voorbeeld van een M:N samengesteld object. Laat zien hoe dat 
object wordt weergegeven met relaties. 

E.21 Geef een voorbeeld van geval 1 van een hybride object (zie Figuur E-22). Laat 
zien hoe dat object wordt weergegeven met relaties. 

E.22 Geef een voorbeeld van geval 2 van een hybride object (zie Figuur E-22). Laat 
zien hoe dat object wordt weergegeven met relaties. 

E.23 Bedenk zelf een voorbeeld van een associatieobject met gerelateerde objecten. 
Laat zien hoe deze objecten worden weergegeven met relaties. Neem aan dat 
het associatieobject een eigen identifier heeft. 

E.24 Doe hetzelfde als voor vraag E.23, maar neem aan dat het associatieobject geen 
eigen identifier heeft. 

E.25 Geef een voorbeeld van een parentobject met minstens twee exclusieve sub- 
typen. Laat zien hoe deze objecten worden weergegeven met relaties. Gebruik 
een type-indicatorattribuut. 

E.26 Geef een voorbeeld van een parentobject met minstens twee niet exclusieve 
subtypen. Laat zien hoe deze objecten worden weergegeven met relaties. Ge- 
bruik een type-indicatorattribuut. 

E.27 Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 
gebruikt, dat goed kan worden gemodelleerd met een enkelvoudig object. Laat 
zien hoe dat object wordt weergegeven met relaties. 

E.28 Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 
gebruikt, dat goed kan worden gemodelleerd met een samengesteld object. 
Laat zien hoe dat object wordt weergegeven met relaties. 
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E.29 Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 


E30 


E.3r 


E32 


E33 


E34 
E.35 


E36 


E37 


gebruikt, dat goed kan worden gemodelleerd met een van de typen van een ge- 
mengd object. Laat zien hoe dat object wordt weergegeven met relaties. 

Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 
gebruikt, dat goed kan worden gemodelleerd met een hybride object. Klassifi- 
ceer het object volgens Figuur E-22 en laat zien hoe het object wordt weergege- 
ven met relaties. 

Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 
gebruikt, dat goed kan worden gemodelleerd met een associatieobject en ge- 
relateerde objecten. Laat zien hoe deze objecten worden weergegeven met 
relaties. 

Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 
gebruikt, dat goed kan worden gemodelleerd met parent/subtype-objecten. 
Laat zien hoe deze objecten worden weergegeven met relaties. 

Zoek een voorbeeld van een formulier dat op jouw school of universiteit wordt 
gebruikt, dat goed kan worden gemodelleerd met archetype/versie-objecten. 
Laat zien hoe deze objecten worden weergegeven met relaties. 

Leg uit waarin het E-R-model en het semantische objectmodel op elkaar lijken. 
Leg uit wat de belangrijkste verschillen zijn tussen het E-R-model en het se- 
mantische objectmodel. 

Licht de redenering toe dat entiteiten, zoals die in het E-R-model worden gede- 
finieerd, niet echt bestaan. 

Laat zien hoe de gegevens in het formulier VERKOOPORDER in Figuur E- 
20(a) kunnen worden weergegeven met het E-R-model en met het semanti- 
sche objectmodel. Leg uit wat de belangrijkste verschillen zijn. 
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Begrippenlijst 


‚NET-framework: Microsofts uitgebreide ontwikkelplatform voor applicaties. Het omvat com- 
ponenten als ADO.NET en ASP.NET. 


[*en */: Symbolen die het begin en einde van commentaar aangeven in SQL-script. 

<?php en ?>: Symbolen die het begin en einde van een PHP-code aangeven in een webpagina. 
rr: Een afkorting voor een een-op-een-relatie tussen entiteiten of tussen rijen van een tabel. 
N: Een afkorting voor een een-op-veel-relatie tussen entiteiten of tussen rijen van een tabel. 
N:M: Een afkorting voor een veel-op-veel-relatie tussen entiteiten of tussen rijen van een tabel. 


Abstract datatype: In SQL3, een door de gebruiker gedefinieerde structuur met methoden, ge- 
gevenselementen en identifiers — een versie van een OOP-object. Persistentie wordt ver- 
kregen door het ADT te binden aan een kolom van een relatie. 


Abstractie: Een generalisatie van iets wat enkele hopelijk onbelangrijke details verbergt, maar 
de mogelijkheid biedt om met een breder typeassortiment te werken. Een recordset is een 
abstractie van een relatie. Een rijset is een abstractie van een recordset. 


ACID-transactie: Een afkorting die staat voor: Atomair, Consistent, geïsoleerd en Duurzaam. 
Bij een atomaire transactie worden alle wijzigingen in de database uitgevoerd als één ge- 
heel — ze worden dus of allemaal of geen van alle uitgevoerd. Bij een consistente transactie 
worden alle bewerkingen uitgevoerd voor rijen in dezelfde logische toestand. Een geïso- 
leerde transactie is een transactie die niet door andere gebruikers kan worden gewijzigd. 
Een duurzame transactie is, nadat deze in de database is doorgevoerd, permanent, onge- 
acht een eventuele volgende storing. Er bestaan verschillende niveaus van consistentie en 
isolatie. Zoek in de index onder ‘consistentie op transactieniveau’, ‘consistentie op state- 
mentniveau’ en ‘transactie-isolatieniveau’. 


Active Server Page: Zie: ASP. 


ActiveX-besturingselement: Een ActiveX-object dat interfaces ondersteunt die toestaan dat de 
eigenschappen en methoden van het besturingselement in veel verschillende ontwikkel. 
omgevingen worden benaderd. 


ActiveX-object: Een COM-object dat een ingekorte versie van de OLE-objectspecificatie 
ondersteunt. 


ADO: Active Data Objects. Een implementatie van OLE DB die toegankelijk is via objectgeori- 
enteerde en niet-objectgeoriënteerde programmeertalen — vooral gebruikt als een script- 
taalinterface (JScript, VBScript) naar OLE DB. 


ADO.NET: Een techniek voor gegevenstoegang die deel uitmaakt van het .NET-initiatief van 
Microsoft. ADO.NET levert alle mogelijkheden van ADO, maar met een andere objecten- 
structuur. ADO.NET omvat ook nieuwe mogelijkheden voor het verwerken van XML en 
het verwerken van datasets. Zie ‘datasets’ voor meer informatie. 
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ADT: Zie: abstract datatype. 


Afhankelijkheidsgrafiek: Een netwerk van knooppunten en lijnen dat de logische afhanke- 
lijkheden weergeeft tussen tabellen, views, triggers, opgeslagen procedures, indexen en 
andere databaseconstructies. 


After image: Een record van een database-entiteit (normaliter een rij of een pagina) na een 
wijziging. Wordt gebruikt in recovery bij het uitvoeren van een rollforward-bewerking. 


Algemene entiteit: In IDEFIX, een entiteit die een of meer categorieclusters heeft. De alge- 
mene entiteit neemt de rol op zich van een supertype voor de categorie-entiteiten in de 
categoriecluster. 


Alternatieve sleutels: Een synoniem voor kandidaatsleutels in logische IDEF1X-modellen. 
Eén of meer kolommen die zullen worden geïndexeerd in een fysiek IDEF1X-model. 


AMP: Afkorting van Apache, MySQL en PHP/Pearl/Python. 


Anomalie: Een ongewenst gevolg van een gegevenswijziging die met name wordt gebruikt 
bij besprekingen van normalisatie. Bij een invoeganomalie moeten gegevens over twee 
of meer verschillende onderwerpen worden toegevoegd als er één rij aan een tabel wordt 
toegevoegd. Bij een verwijderanomalie gaan gegevens over twee of meer onderwerpen 
verloren als er één rij wordt verwijderd. 


API: Zie: applicatieprogramma-interface. 


Applet: Een gecompileerd, machineonafhankelijk Java-bytecodeprogramma dat wordt uitge- 
voerd door de Java virtuele machine die in een browser is ingebed. 


Applicatie: Zie: toepassing. 


Applicatiemetadata: Datadictionary — gegevens die betrekking hebben op de structuur en in- 
houd van toepassingsmenu's, -formulieren en -rapporten. 


Applicatieontwerp: Het creëren van de structuur van programma’s en gegevens om te vol- 
doen aan de specificaties van de toepassing — ook de structuur van de gebruikersinterface. 


Applicatieprogramma: Een intern ontwikkeld programma voor het verwerken van een data- 
base. Het kan zijn geschreven in een standaardtaal zoals Java, C#, VB.NET of C++, of in 
een taal die bij het DBMS hoort, zoals PL/SQL of T-SQL. 


Applicatieprogramma-interface (API): Een verzameling programmaprocedures of functies 
die kunnen worden aangeroepen om een reeks diensten uit te voeren. De API bevat de 
namen van de procedures en functies en een omschrijving van de naam, het doel en het 
gegevenstype van de parameters. Een DBMS-product zou bijvoorbeeld een bibliotheek 
met functies kunnen leveren voor het aanroepen van bepaalde databasediensten. De na- 
men van de procedures en hun parameters vormen de API voor die bibliotheek. 


Applicatiestoring: Een storing bij het verwerken van een DBMS-statement of in een transactie 
ten gevolge van logische fouten in de toepassing. 


Archetype/versie-object: Een uit twee objecten bestaande structuur die verscheidene versies 
van een gestandaardiseerde grootheid voorstelt — bijvoorbeeld een SOFTWAREPRO- 
DUCT (het archetype) en PRODUCTVERSIE (de versie van het archetype). De identifier 
van de versie bevat altijd het archetype-object. 


As: In OLAP, een coördinaat van een kubus of hyperkubus. 
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ASP: Active Server Page. Een bestand, bestaande uit een markeertaal, serverscript en 
clientscript, dat wordt verwerkt door de Active Server Processor in Microsoft IIS. 


pp 


ASP.NET: De vernieuwde versie van ASP voor het .NET-framework 


Associatieobject: Een object dat de combinatie van minstens twee andere objecten vertegen- 
E woordigt en dat gegevens over die combinatie bevat. Een dergelijk object wordt vaak ge- 
bruikt bij toepassingen voor het uitbesteden of toewijzen van zaken. 


Atomair: Een groep acties die als een geheel wordt uitgevoerd. Alle acties worden voltooid, of 
geen ervan. 


Atomaire transactie (ondeelbare transactie): Een groep databasebewerkingen die onderling 
een logisch verband hebben en als één geheel worden uitgevoerd. Dit houdt in dat of alle 
bewerkingen, of geen van alle bewerkingen worden uitgevoerd. 


Attribuut: (t) Een kolom (veld) in een relatietabel. (2) Een eigenschap van een entiteit of se- 
mantisch object. (3) Een gegevens- of relatie-eigenschap in een OOP-object. (4) In het 
ODMG-93 model, een implementatie van een objecteigenschap in een OOP-implemen- 
tatie, zoals C++ of Smalltalk. 


Autorisatieregels: Een verzameling verwerkingsmachtigingen die opleggen welke bewerkin- 
gen gebruikers(groepen) in de database mogen uitvoeren. 


AutoNumber: Het gegevenstype in Access 2007 voor het maken van surrogaatsleutels. 


Basisdomein: In IDEFIX, een domeindefinitie die op zichzelf staat. Er kunnen andere domei- 
nen worden gedefinieerd als subsets van een basisdomein. 


Before image: Een record van een database-entiteit (normaliter een rij of een pagina) voordat 
een gegevenswijziging is uitgevoerd. Wordt bij recovery gebruikt om een rollback-bewer- 
king uit te voeren. 


Berekende waarde (computed value): Een kolom in een tabel waarvan de waarde wordt bere- 
kend op basis van andere kolomwaarden. Waarden worden niet opgeslagen, maar worden 
berekend als ze moeten worden weergegeven. 


Bestaansafhankelijke entiteit: Hetzelfde als een zwakke entiteit. Een entiteit die alleen in de 
database kan voorkomen als er ook instanties zijn van een of meer andere entiteiten. 1D- 
afhankelijke entiteiten vormen een subklasse van bestaansafhankelijke entiteiten. 


Bestandsgegevensbron: Een in een bestand opgeslagen ODBC-gegevensbron die via e-mail of 
op een andere manier onder gebruikers kan worden verspreid. 


BI: Zie Business Intelligence. 
Binaire relatie: Een relatie tussen precies twee entiteiten of tabellen. 


Binding: De koppeling van een programmavariabele of een GUI-besturingselement aan een 
tabelkolom of een query. 


Boomstructuur (tree): Een verzameling records, entiteiten of andere gegevensstructuren 
waarin elk element maximaal één parent heeft, behalve het bovenste element, de wortel, 
die geen parent heeft. 


Bottom-up-databaseontwerp: Een databaseontwerpmethode waarbij vanuit het gedetailleerde 
en specifieke naar een algemene oplossing wordt gewerkt. Deze aanpak leidt vrij snel tot 
resultaten, maar kan resulteren in een database met een beperkt bereik. 
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Boyce-Codd-normaalvorm: Een relatie in derde normaalvorm waarin elke determinant een 
kandidaatsleutel is. 


Branch: Zie: tak. 


Buffer: Een geheugengedeelte waarin gegevens worden bewaard. Gegevens worden vanaf 
een opslagmedium in een buffer gelezen en vanuit de buffer naar een opslagmedium 
geschreven. 


Business Intelligence (BĲ)-Systeem: Informatiesysteem om managers en andere professio- 
nals te helpen bij het analyseren van de huidige en vroegere activiteiten en het voorspellen 
van toekomstige gebeurtenissen. Twee belangrijke categorieën Bl-systemen zijn rapporta- 
gesystemen en dataminingsystemen. 


Callback: Een procedure in objectgeoriënteerde programma's waarbij een object zijn iden- 
titeit doorgeeft aan een ander object met de verwachting dat het aangeroepen object het 
aanroepende object laat weten wanneer er een bepaalde gebeurtenis (event) plaatsvindt. 
Vaak betekent het optreden van die gebeurtenis dat het aangeroepen object wordt vernie- 
tigd, maar de gebeurtenis kan ook een ander doel hebben. 


Cartesisisch product: Een relationele bewerking op twee relaties A en B, met als resultaat een 
derde relatie C die alle mogelijke combinaties bevat van rijen uit A met rijen uit B. 


Cascading deletion: Zie: trapsgewijze verwijdering. 
Cascading updates: Zie: trapsgewijze updates. 


Categoriecluster: In IDEF1X, een groep elkaar tegenzijdig uitsluitende categorie-entiteiten. 
Zie ook: volledige categoriecluster en onvolledige categoriecluster. 


Categorie-entiteit: In IDEF1X, een subtype dat bij een categoriecluster hoort. 


Categorisatierelaties: In IDEF1X, een gestructureerde indeling van subtypen. Zie categorie- 
cluster, categorie-entiteit en algemene entiteit. 


Central Processing Unit: Zie: CPU. 


Check box: Zie: selectievakje. 


Checkpoint: Een synchronisatiepunt tussen een database en een transactielog. Alle buffers 
worden op dit punt geforceerd naar een extern opslagmedium geschreven. Dit is de stan- 
daarddefinitie van checkpoint, maar verschillende DBMS-leveranciers gebruiken deze 
term soms ook op andere manieren. 


Child: Een rij, record of knooppunt aan de veel-kant van een een-op-veelrelatie. 


Client-computer: (1) Een pc in een Local Area Network met client-serverarchitectuur. In een 
databasetoepassing verwerkt de client-computer databaseapplicatieprogramma’s. Verzoe- 
ken voor bewerkingen in de database worden naar de databasecomputer gezonden. (2) In 
de drie- en meerlaagsarchitectuur is het een computer met een browser waarmee toegang 
tot een webserver mogelijk is. 


Client-server-databasearchitectuur: De structuur van een netwerkcomputersysteem waarin 
één computer (meestal een pc) diensten uitvoert namens andere computers (meestal ook 
pc's). In een databasesysteem verwerkt de servercomputer, die ook wel databaseserver 
wordt genoemd, het DBMS, en verwerken clientcomputers de applicatieprogramma’s. 
Alle databaseactiviteiten worden uitgevoerd door de databaseserver. 
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Client-serversysteem: Een svsteem met twee of meer computers waarbij ruimsten 
), | 
puter diensten verleent aan de overige computers. Deze diensten kuren datse 


sen apen 


r 


kingen zijn, maar ook bijvoorbeeld het zorgen voor communicatie of het ter wens 
stellen van printers. 
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Collection: Zie: verzameling. 

COM: Component Object Model. Een Microsoft-specificatie voor het ontwikkelen van 77 
georiënteerde programma's, die het dergelijke programma's mogelijk maakt goed ee 
elkaar samen te werken. 


COM-object: Een object dat in overeenstemming is met de standaard COM. 
Command: Zie: opdracht. 


Commit: Een opdracht die aan het DBMS wordt verstrekt om wijzigingen in de darasese zer 
manent te maken. Zodra de opdracht is verwerkt, worden de wijzigingen op zo 
naar de database en een logbestand geschreven dat ze ook nog bestaan na zer « 
van het systeem of andere storingen. Een doorvoeropdracht wordt mees 
van een atomaire transactie gebruikt. Zie ook: rollback. 


Complex netwerk: Een verzameling entiteiten, objecten of relaties en hun onderlinge 
den, waarbij minstens één van de relaties complex (dus van het type N:M) is. 


Component Object Model: Zie: COM. 
Composite group: Zie: samengestelde groep. 
Composite key: Zie: samengestelde sleutel. 
Composite object: Zie: samengesteld object. 
Compound object: Zie: gemengd object. 


Conceptueel schema: In het model met drie schema's, de volledige, logische weergave va 
de database. 


Concurrency (gelijktijdigheid): Een situatie waarin twee of meer transacties ìn de datehese 
op hetzelfde moment worden verwerkt. In een systeem met één CPU worden de 
kingen door elkaar heen uitgevoerd — in een systeem met verscheidene CPU's X 
transacties werkelijk gelijktijdig worden uitgevoerd en worden de wijzigingen in 
baseserver door elkaar heen uitgevoerd. 


Concurrent processing (gelijktijdige verwerking): De situatie waarin de CPU gemeenscha: 
pelijk wordt gebruikt door diverse transacties. De CPU wordt telkens voor een bepaalde 
tijd aan elke transactie toegekend via een of ander protocol, bijvoorbeeld ‘round-robìn, De 
bewerkingen worden zo snel uitgevoerd dat het voor de gebruikers lijkt alsof ze gelùkeë 
worden uitgevoerd. In LAN's en andere gedistribueerde toepassingen wordt concumveet 
processing gebruikt om te verwijzen naar de (mogelijk werkelijk gelijktijdige) verwerking 
van toepassingen op verscheidene computers. 


Concurrent update probleem (probleem van gelijktijdige wijziging): Een fouttoestand waarde 
de wijzigingen van de ene gebruiker worden overschreven door wijzigingen van een am 
dere gebruiker. Is hetzelfde als het lost update probleem. 


Conflict: Twee bewerkingen zijn ín conflict als ze tegelijkertijd hetzelfde gegevensetement ee 
werken en minstens één van de bewerkingen een schrijfbewerking ìs. 
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Consistent schedule: Een geordende lijst transactiebewerkingen voor een database met een 
consistent resultaat. 


Consistente back-up: Een back-upbestand waaruit alle niet doorgevoerde wijzigingen zijn 
verwijderd. 


Consistentie: Twee of meer gelijktijdig uitgevoerde transacties zijn consistent als het resultaat 
altijd hetzelfde is, ongeacht in welke volgorde de transacties worden uitgevoerd. 


Constraint: Zie: randvoorwaarde. 


CPU: Central Processing Unit. De centrale verwerkingseenheid van de computer die reken- 
kundige en logische instructies uitvoert. De term CPU heeft meestal ook betrekking op 
het werkgeheugen. 


CRUD: Een afkorting van Create, Read, Update, Delete, de vier bewerkingen die op database- 
gegevens kunnen worden uitgevoerd. 


Cursor: Een indicator van de huidige positie of focus. (1) In een computerscherm, een knippe- 
rend vakje of onderstrepingsteken dat aangeeft waar het volgende ingetoetste teken wordt 
weergegeven. (2) In een bestand of in een ingebed SQL SELECT-statement is een cursor 
de identiteit van de volgende te verwerken record of rij. 


Cursortype: Een declaratie van een cursor die bepaalt hoe het DBMS impliciete locks plaatst. 
In dit boek worden vier cursortypen behandeld, namelijk forward only, statische (snap- 
shot), keyset en dynamische. 


Data Definition Language (DDL): Een taal die wordt gebruikt voor het beschrijven van de 
structuur van een database. 


Data Manipulation Language (DML): Een taal die wordt gebruikt voor het verwerken van een 
database. 


Data proponent: Zie: gegevensverantwoordelijke. 
Database: Een zichzelf beschrijvende verzameling geïntegreerde records. 


Database herontwerpen: Het proces van het wijzigen van databasestructuren voor het aanpas- 
sen van de database aan veranderende eisen (of voor het repareren van de database, om 
deze de structuur te geven die deze eigenlijk van begin af aan had moeten hebben). 


Database Management System: Zie DBMS. 


Database save: Een kopie van de databasebestanden waarmee de database kan worden terug- 
gebracht naar een eerdere, consistente toestand. 


Databasebeheer: De afdeling binnen een organisatie die zich bezighoudt met het effectief ge- 
bruiken en beheren van een bepaalde database en de daarbij horende toepassingen. 


Databasebeheerder (DBA): De persoon of groep die verantwoordelijk is voor het opstellen en 
handhaven van beleid en procedures voor het beheren en beschermen van een database. 
Hij of zij werkt volgens richtlijnen van het gegevensbeheer voor het beheren van de data- 
basestructuur, het beheren van wijzigingen en het onderhouden van DBMS-programma's. 


Databasegegevens: Het deel van een database waarin gegevens staan die voor de eindgebrui 
kers van de toepassing van belang zijn. 


Databaseserver: (1) De computer in een LAN met een client-server databasearchitec- 
tuur, waarop het DBMS draait en die bewerkingen op de database uitvoert namens de 
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clientcomputers. (2) In de drie- of meerlaagsarchitectuur is dit een computer met een 
DBMS die reageert op databaseverzoeken van de webserver. 

Datadictionary: Een catalogus met database- en applicatiemetadata die voor de gebruiker toe- 
gankelijk is. Een actieve datadictionary is een dictionary waarvan de inhoud automatisch 
door het DBMS wordt bijgewerkt als er wijzigingen in de database- of applicatiestructuur 
worden aangebracht. Bij een passieve datadictionary moet de inhoud handmatig worden 
bijgewerkt als er wijzigingen worden uitgevoerd. 

Datadictionary- en databasebeheer-subsysteem: Een verzameling programma’s in het DBMS 
voor het benaderen van de datadictionary en het uitvoeren van functies voor het data- 
basebeheer, zoals het bijhouden van wachtwoorden en het uitvoeren van back-ups en 
recoverywerkzaamheden. 

Datamart: Een soortgelijke voorziening als een datawarehouse, maar voor een beperkt do- 
mein. Vaak zijn de gegevens beperkt tot bepaalde typen, zakelijke functies of business 
units. 

Dataminingsysteem: Een business intelligence systeem dat geavanceerde statistische en wis- 
kundige technieken gebruikt om wat-als analyses te maken, voorspellingen te doen, en 
beslissingen te ondersteunen. Tegenhanger is rapportagesysteem. 

Dataset: In ADO.NET, een alleen in het geheugen bestaande verzameling van tabellen, die 
niet aan welke database dan ook is gekoppeld. Datasets hebben relaties, referentiële inte- 
griteitsvoorwaarden, referentiële integriteitsacties en andere belangrijke kenmerken van 
databases. Ze worden verwerkt door ADO.NET-objecten. Een enkele dataset kan zichzelf 
materialiseren in de vorm van tabellen, een XML-document of een XML-Schema. 


Datasubtaal: Zie: gegevenssubtaal. 


Datawarehouse (gegevenspakhuis): Een opslagplaats van bedrijfsgegevens die is ontwikkeld 
om de besluitvorming op managementniveau te vereenvoudigen. Een datawarehouse be- 
vat niet alleen gegevens, maar ook metadata, tools, procedures, opleidingen, personeel en 
andere bronnen die het verkrijgen van gegevens eenvoudiger en relevanter maken voor 


besluitvormers. 


DBA: Zie: databasebeheerder. 


DBMS: Database Management System — een verzameling programma's voor het definiëren, 
beheren en verwerken van de database en de bijbehorende toepassingen. 


DBMS-engine: Een DBMS-subsysteem dat logische I/O-verzoeken van andere DBMS-subsys- 
temen verwerkt en fysieke I/O-verzoeken naar het besturingssysteem verstuurt. 


DDBMS: Zie: Distributed Database Management System. 


DDL: Zie: Data Definition Language. 


Deadlock: Een situatie die kan optreden tijdens gelijktijdige verwerking (concurrent pro- 
cessing), waarbij twee of meer transacties allemaal wachten tot ze toegang krijgen tot 
gegevens die door een van de andere transacties zijn gelockt. Wordt ook wel ‘dodelijke 


omhelzing’ genoemd. 
Deadlockdetectie: Het proces van het bepalen of twee transacties zich al dan niet in een dead- 


locktoestand bevinden. 
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Deadlockpreventie: Een manier voor het beheren van transacties die voorkomt dat er een 
deadlock kan plaatsvinden. 


Decision Support System: Zie: DSS. 
Default namespace: Zie: standaardnaamruimte. 


Definitietools-subsysteem: Het deel van het DBMS-programma dat wordt gebruikt om de da- 
tabasestructuur te definiëren en te wijzigen. 


Derde normaalvorm: Een relatie in tweede normaalvorm zonder transitieve afhankelijkheden. 


Determinant: Een of meer attributen die een ander attribuut of andere attributen functioneel 
bepalen. In de functionele afhankelijkheid (A, B) ® C, dan zijn de attributen (A, B) de 
determinant. 


Dienstverlener: Zie: serviceprovider. 


Differentiële back-up: Een back-upbestand waarin alleen wijzigingen staan die zijn uitge- 
voerd sinds de vorige back-up. 


Dimensie: In OLAP, een kenmerk van gegevens dat langs een as wordt uitgezet. 


Dirty read: Het lezen van gegevens die zijn gewijzigd maar nog niet definitief in de database 
zijn doorgevoerd. Zulke wijzigingen kunnen later worden teruggedraaid en uit de data- 
base worden verwijderd. 

Discriminator: In IDEF1X, een attribuut van een algemene entiteit die kan worden gebruikt 
om te bepalen welke categorie-entiteit van een categoriecluster betrekking heeft op een 
gegeven instantie van een algemene entiteit. 


Distributed Database Management System (DDBMS): In een gedistribueerde database, de 
verzameling van gedistribueerde transacties en databasemanagers op alle computers. 


Distributed Transaction Service (DTS): Een door Microsoft ontwikkelde OLE-service die ge- 


distribueerde verwerking ondersteunt en, in het bijzonder, een tweefasedoorvoeralgorit- 
me implementeert. 


DK/NF: Zie: domein/sleutel-normaalvorm. 
DML (Data Manipulation Language): Zie: DML. 


Document Object Model (DOM): Een API die een XML-document voorstelt als een boom- 
structuur. Elk knooppunt van de boomstructuur vertegenwoordigt een deel van het 
XML-document. Een programma kan een knooppunt van de DOM-representatie direct 
benaderen en bewerken. 


Document Type Declaration (DTD): Een verzameling markeerelementen die de structuur van 
een XML-document definieert. 


Dodelijke omhelzing: Zie: deadlock. 
Doelnaamruimte: Zie: target namespace. 
DOM: Zie: Document Object Model. 


Domein: Een benoemde verzameling die alle mogelijke waarden bevat die een attribuut kan 
hebben. Domeinen kunnen gedefinieerd worden door een lijst van toegestane waarden op 
te geven, of door een regel op te geven die bepaalt welke waarden toegestaan zijn. 
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Domein/sleutel-normaalvorm (DK/NF): Een relatie waarbij alle randvoorwaarden logische 


gevolgen zijn van domeinen en sleutels. 


Doorsnederelatie: Een relatie die wordt gebruikt voor het representeren van veel-op-veelrela- 
ties. Bevat de sleutels van de relaties in de relatie. Een doorsnederelatie transformeert een 
N:M-relatie in twee t:N-relaties. In IDEF1X wordt een doorsnederelatie gebruikt voor het 
representeren van een niet specifieke relatie. 

Downloaden: Het kopiëren van databasegegevens van de ene computer naar de andere, 
meestal van een mainframe of mini naar een pc of LAN. 


Drielaagsarchitectuur (three-tier architecture): Een computersysteem met een databaseser- 
ver, een webserver en een of meer clientcomputers. De databaseserver fungeert als een 
DBMS, de webserver als een http-server en de client-computer als een browser. Op elke 
laag of tier kan een ander besturingssysteem draaien. 

Drill-down: Een door de gebruiker gestuurde disaggregatie van gegevens om totalen op een 
hoger niveau op te splitsen in componenten. 


Driver: Zie: stuurprogramma. 
Driver manager: Zie: stuurprogramma-manager. 
DSD (Data Structure Diagram): Zie: gegevensstructuurdiagram. 


DSS: Decision Support System (beslissingsondersteunend systeem). Een interactieve com- 
putertoepassing voor het ondersteunen van te nemen besluiten, vooral als er sprake is 
van semi-gestructureerde en ongestructureerde problemen. Een dergelijk systeem is 
vaak voorzien van een database en een query/updatevoorziening voor het verwerken van 
ad-hocverzoeken. 


DTD: Zie: Document Type Declaration. 
DTS: Zie: Distributed Transaction Service. 


ECMAScript-262: De standaardversie van een vrij eenvoudige geïnterpreteerde taal voor het 
verwerken van webserver- en webclient-toepassingen. De Microsoft-versie heet JScript en 
de Netscape-versie heet JavaScript. 

Een-op-veel-relatie: Een relatie waarbij een parent (of een rij in een parenttabel) gerelateerd 
is aan veel childinstanties (of rijen in een childtabel). Tegelijkertijd kan een childinstan- 
tie (of rij in de childtabel) gerelateerd zijn aan slechts een parentinstantie (of rij in de 
parenttabel). 

Een-op-een-relatie: Een relatie waarbij een parent (of een rij in een parenttabel) gerelateerd 
is aan slechts een childinstantie (of rij in een childtabel). Tegelijkertijd kan een childin- 
stantie (of rij in de childtabel) gerelateerd zijn aan slechts een parentinstantie (of rij in de 
parenttabel). 

Eenlaagsstuurprogramma (single-tier driver): In ODBC, een databasestuurprogram:- 
ma dat SQL-statements van de stuurprogramma-manager accepteert en deze 
verwerkt zonder een ander programma of DBMS aan te roepen. Een eenlaagsstuur- 
programma is zowel een ODBC-stuurprogramma als een DBMS — wordt gebruikt voor 
bestandsverwerkingssystemen. 

Eenvoudig netwerk: () Een verzameling van drie relaties en twee relaties waarbij een van de 
relaties, R,‚ een veel-op-eenrelatie heeft met de andere twee relaties. De rijen in R hebben 
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twee parents en de parents zijn elk van een ander type. (2) Elke verzameling tabellen en 
relaties waarin de in (1) gedefinieerde structuur voorkomt. 

Eenvoudig object: Een object zonder herhaalde attributen en zonder objectattributen. 

Eerste normaalvorm: Elke tabel die voldoet aan de definitie van een relatie. 

Eigenaar (Owner): Bij gegevensbeheer, de persoon of afdeling die verantwoordelijk is voor het 
beheren van een bepaald gegevenselement. Zie ook: gegevensverantwoordelijke. 

Eigenschap (property): Zie: attribuut. 


Enkelwaardig attribuut: In een semantisch object, een attribuut met een maximumkardina- 
liteit van één. 

Enterprise Java Beans: Een faciliteit voor het beheren van gedistribueerde objecten en gedis- 
tribueerde verwerking in de Java-ontwikkelomgeving. 


Entiteit: (1) lets wat belangrijk is voor een gebruiker, dat in een database moet worden gere- 
presenteerd. (2) In het E-R-model zijn entiteiten grootheden die beperkt zijn tot op dingen 
die door een enkele tabel kunnen worden gerepresenteerd. 


Entiteit-relatiediagram (E-R-diagram): Een grafische weergave van entiteiten en hun onder- 
linge samenhang. Entiteiten worden in het traditionele E-R-model meestal weergegeven 
als vierkanten of rechthoeken en hun onderlinge samenhang (relaties) door ruitvormige 
figuren. De kardinaliteit van de relatie wordt binnen de ruit aangegeven. Zie ook: IDEFIX. 


Entiteit-relatiemodel (E-R-model): De constructies en afspraken voor het opstellen van een 
model van de gebruikersgegevens (zie ook: gegevensmodel). De grootheden uit de gebrui- 
kersomgeving worden voorgesteld door entiteiten en de samenhang tussen die groothe- 


den door relaties tussen entiteiten. De resultaten worden meestal gedocumenteerd in een 
E-R-diagram. 


Entiteitsinstantie: Een bepaalde instantie van een entiteit, zoals Medewerker roo, of de Afde- 
ling Boekhouding. 


Entiteitsklasse: Een verzameling entiteiten van hetzelfde type, zoals MEDEWERKER of 
AFDELING. 


Enumeratielijst: Een lijst met toegestane waarden voor een domein, attribuut of kolom. 


Equi-join: De samenvoeging van relatie A met attribuut Ar en B met attribuut Br met als re- 


sultaat een relatie C, zodat voor elke rij in C geldt dat Ar = Br. De attributen Ar en Br wor- 
den beide in C opgenomen. 


E-R-diagram: Zie: entiteit-relatiediagram. 
E-R-model: Zie: entiteit-relatiemodel. 


Exclusieve lock: Een lock op een gegevensbron, zodat geen andere transactie deze kan lezen 
of wijzigen. 


Expliciete lock: Een lock die het resultaat is van een opdracht in een applicatieprogramma. 


Exporteren: Een service van een DBMS die gegevens uit de database extraheert in een bestand. 
Het bestand is bedoeld om te worden gelezen door een ander DBMS of programma. 


Extent (van object): In het ODMG-model de vereniging (union) van alle objectinstanties. At- 
tributen kunnen uniek worden verklaard binnen de extent van een object. 
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Extern schema: In het model met drie schema's, de subset van de database die door een ge- 
bruiker of een groep gebruikers wordt bekeken. Synoniem voor gebruikersweergave of 


user view. k 

} 
Externe sleutel (foreign key): Een attribuut in een tabel dat een sleutel is voor een of meer an- 4 
dere relaties. Wordt gebruikt voor het representeren van relaties. 


LAN of pc waar de gegevens lokaal worden verwerkt. Dergelijke uittreksels worden ge- 
maakt om communicatiekosten en -tijd te besparen bij het zoeken in en maken van rap- 
porten van gegevens die door transactieverwerking zijn gecreëerd. Î 
F-score: De frequentie (in RFM-analyse) die weergeeft hoeveel keer een klant een aankoop 
doet. 
Flat file (plat bestand): Een bestand met slechts één waarde in elk veld. De betekenis van een 
kolom is in elke rij gelijk. 
Force-write (geforceerde schrijfinstructie): Het wegschrijven van databasegegevens waarbij 
het DBMS wacht op bevestiging van het besturingssysteem dat het after image van de 
schrijfinstructie met succes naar het logbestand is geschreven. 


Extract (uittreksel): Een deel van een operationele database dat wordt gedownload naar een | ij 
Î 
Û 


Foreign key: Zie: externe sleutel. 


Forward engineering: Het geautomatiseerde proces dat wijzigingen in het gegevensmodel ge- 
bruikt voor het uitvoeren van wijzigingen in de databasestructuur. Forward engineering 


wordt geleverd als een mogelijkheid van hulpprogramma's voor gegevensmodellering, 
zoals ERWin en Visio. 

Fragment: Een rij in een tabel (of een record in een bestand) waarin een vereiste parent of 
child ontbreekt. Bijvoorbeeld een rij in een ORDERREGEL-tabel waarvoor geen ORDER- 
rij bestaat. 


Functionele afhankelijkheid: Een relatie tussen attributen waarbij de waarde van een attri- 
buut of een groep attributen de waarde van een ander attribuut bepaalt. De uitdrukkingen 
XY’, ‘X bepaalt Y' en ‘Y is functioneel afhankelijk van X’ betekenen dat we de waarde 


van Y kunnen bepalen als we de waarde van X kennen. 


Fysieke sleutel: Een kolom waarvoor een index of een andere gegevensstructuur is gecreëerd. 
Een synoniem voor een index. Dergelijke structuren worden gecreëerd om kolomwaarden 


sneller te kunnen doorzoeken en sorteren. 
Gebruikersgegevensbron: Een ODBC-gegevensbron die alleen beschikbaar is voor de gebrui- 
ker die hem heeft gecreëerd. 


Gecorreleerde subquery: Een soort subquery waarin een element in de subquery naar een ele- 
ment in de omvattende query verwijst. Dergelijke subquery’s vereisen geneste verwerking. 


Gedeelde lock: Zie: shared lock. 

Gedistribueerd databasesysteem: Een gedistribueerd systeem waarin (delen van) een data- 
base worden verdeeld over twee of meer computers. 

Gedistribueerd systeem: Een systeem waarin de applicatieprogramma's van een database op 
twee of meer computers worden verwerkt. 


Gedistribueerde database: Een op twee of meer computers opgeslagen database. Gedistribu- 
eerde gegevens kunnen al dan niet gepartitioneerd en al dan niet gerepliceerd zijn. 
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Gedistribueerde databasetoepassing: Een zakelijk computersysteem waarbij het ophalen en 
bijwerken van gegevens is verdeeld over twee of meer onafhankelijke en meestal geogra- 
fisch van elkaar gescheiden computers. 


Gedistribueerde databaseverwerking: Databaseverwerking waarbij transactiegegevens wor- 
den opgehaald en bijgewerkt die zijn verdeeld over twee of meer onafhankelijke en meest- 
al geografisch van elkaar gescheiden computers. 


Gedistribueerde tweefaselocking: Tweefaselocking in een gedistribueerde omgeving. 
Locks worden over alle knooppunten in het netwerk geplaatst en vrijgegeven. Zie ook: 
tweefaselocking. 


Geforceerde schrijfinstructie: Zie: force-write. 


Gegeneraliseerde hiërarchie: Een verzameling objecten of entiteiten van hetzelfde logische 
type die zijn gerangschikt in een hiërarchie van logische subtypen. MEDEWERKER heeft 
bijvoorbeeld als subtypen INGENIEUR en ACCOUNTANT, en INGENIEUR heeft als 
subtypen ELEKTROTECHNISCH INGENIEUR en WERKTUIGBOUWKUNDIG INGE- 
NIEUR. Subtypen erven de kenmerken van hun supertypen. 


Gegevensbeheer: De activiteiten ten behoeve van de gehele onderneming die betrekking heb- 
ben op het effectief gebruiken en het beheren van de gegevens binnen de organisatie. Dat 
kan door één persoon gedaan worden, maar het wordt meestal door een groep gedaan. 
Specifieke taken zijn het opstellen van gegevensstandaarden en -beleid en het bemiddelen 
bij gegevensconflicten. Zie ook: databasebeheerder. 


Gegevensbron: In de ODBC-standaard is dit een database, samen met het bijbehorende 
DBMS, besturingssysteem en netwerkplatform. 


Gegevensconsument: Een gebruiker van OLE DB-functionaliteit. 
Gegevenseigenaar: Zie: gegevensverantwoordelijke. 


Gegevenselement: (1) Een logische groep bytes in een record, meestal gebruikt bij bestands- 
verwerking. (2) In de context van het relationele model is het een synoniem voor attribuut. 


Gegevensintegriteit: De toestand van een database waarbij aan alle randvoorwaarden wordt 
voldaan — heeft meestal betrekking op referential integrity constraints waarbij de waarde 


van de externe sleutel moet voorkomen in de tabel waarin deze externe sleutel de primaire 
sleutel is. 


Gegevensleverancier (data provider): Een leverancier van OLE DB-functionaliteit. Voorbeel- 
den zijn leveranciers van tabelgegevens en serviceproviders. 


Gegevensmodel: (1) Een model van de gegevensbehoefte van de gebruikers, uitgedrukt in ter- 
men van het E-R-model of het semantische objectmodel. Wordt ook wel gebruikersgege- 
vensmodel genoemd. (2) Een taal voor het beschrijven van de structuur en het verwerken 
van een database. 


Gegevensreplicatie: Een term die aangeeft of een deel van de gegevens of alle gegevens in 
een database op meer dan één computer staan. Als dat het geval is, zijn de gegevens 
gerepliceerd. 


Gegevensstructuurdiagram: Een grafische weergave van tabellen (bestanden) en hun onder- 
linge relaties. De tabellen worden als rechthoeken weergegeven en hun onderlinge rela- 
ties door verbindingslijnen. De veel-kant van een relatie wordt aangegeven door een vork 
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aan het eind van de lijn, een optionele relatie wordt met een rondje aangeduid en een ver- 
plichte relatie wordt voorzien van een streepje. 

Gegevenssubtaal: Een taal voor het definiëren en verwerken van databases, die is bedoeld om 
te worden ingebed in programma's die in een andere taal zijn geschreven — meestal is dat 
een proceduregerichte taal zoals Java, C# of Visual Basic of C++. Een gegevenssubtaal is 
een incomplete programmeertaal, omdat deze alleen constructies omvat voor het krijgen 
van toegang tot gegevens. 

Gegevensverantwoordelijke (data proponent): In het gegevensbeheer, een afdeling of een 
andere organisatie-eenheid die verantwoordelijk is voor het beheren van een bepaald 
gegevenselement. 

Gelabelde naamruimte: In een XML Schemadocument, een naamruimte waaraan een naam 
(label) wordt gegeven in het document. Van alle elementen die vooraf worden gegaan door 
de naam van de gelabelde naamruimte wordt aangenomen dat ze in die gelabelde naam:- 
ruimte zijn gedefinieerd. 

Gelijktijdige verwerking: Zie: concurrent processing. 

Gemengd object (compound object): Een object dat minstens één ander object bevat. 

Gemengde partitie: Een combinatie van een horizontale en een verticale partitie. Bijvoorbeeld 
de eerste drie kolommen van de eerste drie rijen in een tabel met vijf kolommen en vijf 
rijen. 

Generalisatieobject: Een object dat subtype-objecten bevat. Het generalisatieobject en zijn 
subtypen hebben allemaal dezelfde sleutel. Subtype-objecten erven attributen van het ge- 
neralisatieobject. Een generalisatieobject wordt ook wel een supertype-object genoemd. 

Gerepliceerde gegevens: In een gedistribueerde database, gegevens die op twee of meer com- 
puters zijn opgeslagen. 

Graad: Bij relaties in het E-R-model, het totale aantal entiteiten dat aan de relatie deelneemt. 
Dergelijke relaties zijn vrijwel altijd van de graad 2. 


Granulariteit: De omvang van de te locken databasebron. Als de gehele database wordt ge- 
lockt, is de granulariteit grof, als een kolom van een afzonderlijke rij kan worden gelockt, 


is er sprake van een erg fijne granulariteit. 

Groeifase: De eerste fase bij tweefaselocking waarin locks worden geplaatst maar niet worden 
vrijgegeven. 

Groepsidentifier: Een attribuut dat een unieke instantie van een groep identificeert binnen 
een semantisch object of een andere groep. 

HEEFT-EEN-relatie: Een relatie tussen twee entiteiten of objecten van een verschillend lo- 
gisch type. Bijvoorbeeld MEDEWERKER HEEFT-EEN AUTO. Zie ook: IS-EEN-relatie. 


Hiërarchisch gegevensmodel: Een gegevensmodel dat alle verbanden weergeeft met behulp 
van hiërarchieën of boomstructuren. Netwerkstructuren moeten eerst in boomstructuren 
worden omgezet voordat ze door een hiërarchisch gegevensmodel kunnen worden voor- 
gesteld. DL/L is het enige nog bestaande voorbeeld van een hiërarchisch gegevensmodel. 

HOLAP: Hybride OLAP, waarbij gebruik wordt gemaakt van een combinatie van ROLAP en 
MOLAP voor het ondersteunen van van OLAP-verwerking. 


Horizontale beveiliging: Beperkte toegang tot bepaalde rijen van een tabel of join. 
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Horizontale partitie: Een deelverzameling van een tabel die bestaat uit complete rijen van de 
tabel. Bijvoorbeeld de eerste vijf rijen in een tabel met tien rijen. 


Hostvariabele: Een variabele in een applicatieprogramma waarin een DBMS een waarde uit 
de database kan plaatsen. 


HTML: Zie: HyperText Markup Language. 
Http: Zie: HyperText Transfer Protocol. 


Hybride object: Een object met een meerwaardige groep die minstens één objectattribuut 
bevat. 


Hyperkubus: In OLAP, een presentatiestructuur met vier of meer assen waarlangs gegevens- 
dimensies worden uitgezet. De maateenheden van de gegevens staan in de cellen van de 
hyperkubus. Zie ook: kubus. 


HyperText Markup Language (HTML): Een gestandaardiseerd systeem waarbij wordt gewerkt 
met tags voor het opmaken van tekst en het opnemen van afbeeldingen en andere niet- 
tekstbestanden en het opnemen van verwijzingen of links naar andere documenten. 


HyperText Transfer Protocol (http): Een gestandaardiseerde methode voor het overdragen van 
HTML-documenten over netwerken via TCP/IP. 


ID-afhankelijke entiteit: Een entiteit die logisch gezien alleen samen met een andere entiteit 
kan bestaan. Een AFSPRAAK kan bijvoorbeeld alleen bestaan als er ook een KLANT is 
waarmee die afspraak is gemaakt. De identifier van de ID-afhankelijke entiteit bevat altijd 
de sleutel van de entiteit waarvan zij afhankelijk is. Dergelijke entiteiten zijn een subset 
van een zwakke entiteit. Zie ook: sterke entiteit en zwakke entiteit. 


IDEFIX: Een versie van het entiteit-relatiemodel dat in 1993 tot een Amerikaanse nationale 
standaard is benoemd. 


Identificerende verbindingsrelatie: In IDEFIX, een r:1 of r:N HEEFT-EEN-relatie waarin de 
childentiteit ID-afhankelijk is van de parent. 


IIS: Internet Information Server. Een Microsoft-product dat als een http-server fungeert. [IS 
wordt bij Windows Professional 2000/XP geleverd. 


Implementatie: In OOP, een verzameling objecten die een instantie maakt van een bepaalde 
OOP-interface. 


Impliciete lock: Een lock die automatisch door het DBMS wordt geplaatst. 
Importeren: Het inlezen van bestanden of gegevens door het DBMS. 


Inconsistent read probleem: Een anomalie die optreedt bij gelijktijdige verwerking, waarbij 
transacties een reeks leesacties uitvoeren die niet consistent met elkaar zijn. Kan worden 
voorkomen door tweefaselocking en andere strategieën. 


Inconsistente back-up: Een back-upbestand die niet-doorgevoerde wijzigingen bevat. 


Index: Overheadgegevens die worden gebruikt voor het verbeteren van de toegankelijkheid en 
de prestaties van het sorteren. Indexen kunnen worden geconstrueerd per kolom of voor 
groepen kolommen. Ze zijn vooral handig voor kolommen die worden gebruikt voor con- 
trol breaks in rapporten en voor het opgeven van voorwaarden in joins. 

Information Engineering: Een door James Martin ontwikkelde versie van het 
entiteit-relatiemodel. 
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Ingebouwde functie (standaardfunctie): In SQL zijn dit bijvoorbeeld de functies COUNT, 
SUM, AVG, MAX en MIN. 


Ingekapselde gegevens: Eigenschappen of attributen in een programma of object die niet 
zichtbaar of toegankelijk zijn voor andere programma’s of objecten. 


Ingekapselde structuur: Een deel van een object dat niet zichtbaar is voor andere objecten. 
Inheritance: Zie: overerving. 
Inner join: Synoniem voor Join. Zie ook: outer join. 


Instantiestoring: Een storing in het besturingssysteem of de hardware die ervoor zorgt dat het 
DBMS niet meer werkt. 


Integrated Definition 1, Extended: Zie: IDEF:X. 
Integrated definition for information modeling: Zie: IDEFIX. 


Interface: (1) De wijze waarop twee of meer programma’s met elkaar communiceren — de defi- 
nitie van de proceduregerichte aanroepen tussen twee of meer programma's. (2) In OOP, 
het ontwerp van een verzameling objecten waaronder de namen, methoden en attributen 
van die objecten. 

Intern schema: In het model met drie schema's, een representatie van een conceptueel 
schema, zoals dat fysiek wordt opgeslagen met een bepaald product en/of een bepaalde 


techniek. 


Internet Information Server: Zie IIS. 

Invoeganomalie: In een relatie, de situatie die optreedt als er gegevens over twee of meer lo- 
gisch gezien verschillende onderwerpen moeten worden toegevoegd om een complete rij 
aan een tabel te kunnen toevoegen. 

IS-EEN-relatie: Een relatie tussen twee entiteiten of objecten van hetzelfde logische type, 
waarbij de ene entiteit een subtype is van de andere. Een INGENIEUR is bijvoorbeeld een 
subtype van MEDEWERKER en heeft een IS-EEN-relatie met MEDEWERKER. 


Isolatieniveau: Zie: transactie-isolatieniveau. 

IUnknown: Een ActiveX-interface waarin een ActiveX-programma een ander, onbekend Ac- 
tiveX-prograrmma kan aanroepen. Zodra er een verbinding tot stand is gebracht, kan het 
eerste programma gebruikmaken van de queryinterface om te bepalen welke objecten, 
methoden en eigenschappen het tweede programma ondersteunt. 

Java: Een objectgeoriënteerde programmeertaal met een beter geheugenbeheer en een betere 
array grenscontrole dan C++. Deze taal wordt voornamelijk gebruikt voor Internettoepas- 
singen, maar kan ook als een gewone programmeertaal worden gebruikt. Java-compilers 
genereren Java-bytecode die op clientcomputers wordt geïnterpreteerd. 

Java Server Page (JSP): Een combinatie van HTML en Java die wordt gecompileerd in een 
Java-servlet die een subklasse is van de klasse HttpServlet. Java-code die is ingebed in een 
JSP heeft toegang tot http-objecten en -methoden. JSP-pagina's worden op vrijwel dezelf. 
de manier gebruikt als ASP-pagina’s, maar worden gecompileerd en niet geïnterpreteerd 
zoals bij ASP-pagina’s het geval is. 

Java virtuele machine: Een Java-bytecode-interpreter die draait onder een bepaalde machine- 
omgeving, zoals Intel 386 of Alpha. Zulke interpreters zijn meestal ingebed in browsers 
of maken deel uit van het besturingssysteem of van een Java-ontwikkelomgeving. 
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Java-bean: Een Java-klasse die zich op de juiste manier gedraagt. Beans hebben geen open- 
bare instantievariabelen — al hun persistente waarden worden benaderd via accessorme- 
thoden en ze hebben geen constructors, of precies één expliciet gedefinieerde constructor 
zonder argumenten. 


JavaScript: Een scripttaal van Netscape. De Microsoft-versie heet JScript en de standaardver- 
sie heet ECMAScript-262. Dit zijn vrij eenvoudig te leren geïnterpreteerde talen voor het 
verwerken van webserver- en webclient-toepassingen. Wordt soms geschreven als ‘Java 
Script’. 

Java-servlet: Zie: servlet. 


JDBC: Een standaardinterface aan de hand waarvan in Java geschreven applicatieprogram- 
ma's SQL-databases (of tabelstructuren zoals spreadsheets en teksttabellen) op een DB- 
MS-onafhankelijke manier kunnen benaderen en verwerken. De naam is geen afkorting 
van Java Database Connectivity. 


Join (samenvoeging): Een relationele algebrabewerking op twee relaties A en B, met als resul- 
taat een relatie C, Een rij van A wordt alleen aaneengeschakeld met een rij van B tot een 
rij in C als de rijen in A en B voldoen aan beperkingen voor hun waarden. Als Ar bijvoor- 
beeld een attribuut in A is en Br een attribuut in B, dan resulteert de join van A en B met 
als randvoorwaarde Ar < Br in een relatie C met de aaneenschakeling van rijen in A en B 
waarvoor geldt dat de waarde van Ar kleiner is dan de waarde van Br. Zie ook: equi-join 
en natural join. 


JScript: Een scripttaal van Microsoft. De Netscape-versie heet JavaScript en de standaardver- 
sie heet ECMAScript-262. Dit zijn vrij eenvoudig te leren geïnterpreteerde talen voor het 
verwerken van webserver- en webclient-toepassingen. 


JSP: Zie Java Server Page. 


Kandidaatsleutel: Een attribuut dat of een groep met attributen die een rij in een relatie op 
unieke wijze identificeert. Een van de kandidaatsleutels wordt gekozen als de primaire 
sleutel. 


Kardinaliteit: In een binaire relatie, het maximaal toegestane of minimaal benodigde aantal 
elementen aan elke kant van de relatie. De maximumkardinaliteit kan r:1, r:N, N:1 of N:M 
zijn. De minimumkardinaliteit kan optioneel-optioneel, optioneel-verplicht, verplicht-op- 
tioneel of verplicht-verplicht zijn. 


Keuzelijst (list box): In een GUI-omgeving, een element van de gebruikersinterface waarin 
een lijst met keuzemogelijkheden in een rechthoek wordt weergegeven. Het door de ge- 
bruiker met de cursor aangewezen item wordt in een andere kleur weergegeven dan de 
overige regels in de lijst. 


Keuzerondje (option button, radio button): In een GUI-omgeving, een element van de gebrui- 
kersinterface waarin de gebruiker een item uit een lijst kan kiezen. Als op het ene rondje 
wordt geklikt, wordt automatisch de selectie van elk ander eventueel op dat moment gese- 
lecteerde rondje ongedaan gemaakt. Werkt dus als de zenderkeuzeknop op een radio en 
is hetzelfde als een ‘radio button’, maar is wegens auteursrechten onder een andere naam 


geïntroduceerd. 


Key: Zie: sleutel. 
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Klassenattributen: In UML (Uniform Modeling Language) zijn dat attributen die betrekking 
hebben op de klasse van alle entiteiten van een bepaald type. 


Knooppunt (Node): (r) Een entiteit in een boomstructuur. (2) Een computer in een systeem 
voor gedistribueerde verwerking. 

Kolom: Een logische groep bytes in een rij van een relatie of een tabel. De betekenis van een 
kolom is gelijk voor elke rij in de relatie. 

Kolomobject: In Oracle, een objectstructuur die is opgeslagen in een tabelkolom. 

Krimpfase: In tweefaselocking, de fase waarin locks worden vrijgegeven en er geen locks 
meer worden geplaatst. 

Kubus: In OLAP, een presentatiestructuur met assen waarlangs gegevensdimensies wor- 
den geplaatst. Maateenheden van de gegevens staan in de cellen van de kubus. Zie ook: 
hyperkubus. 

LAMP: AMP dat onder Linux draait. Zie AMP. 


Leden (members): In OLAP, de waarden van een dimensie. 


List box: Zie: keuzelijst. 


Lock: Het proces van het toekennen van een databasebron aan een bepaalde transactie in een 
systeem voor gelijktijdige verwerking. De omvang van de gelockte bron staat bekend als 
de lockgranulariteit. Bij een exclusieve lock kan geen enkele andere transactie de bron le- 
zen of ernaar schrijven. Bij een shared lock mogen andere transacties de bron wel lezen, 


maar er niet naar schrijven. 


Lockgranulariteit: De omvang van een gelockt gegevenselement. De lock van een kolomwaar- 
de van een bepaalde rij is een lock met een fijne granulariteit en de lock van een complete 


tabel is een lock met een grove granulariteit. 

Log (logboek): Een bestand waarin alle databasewijzigingen worden vastgelegd. Het log bevat 
before images en after images. 

Lost update probleem: Zie: concurrent update probleem. 

M-score: Score (in RFM-analyse) die weergeeft hoeveel geld een klant per aankoop besteedt. 


Many-to-many (N:M) relatie: Zie: veel-op-veel-relatie. 

Maateenheid: In OLAP, de brongegevens voor de kubus — gegevens die in de cellen worden 
weergegeven. Dat kunnen oorspronkelijke gegevens zijn, of functies van deze gegevens, 
zoals SUM, AVG of andere berekeningen. 

Materialisatie: Een databaseview zoals die verschijnt in een formulier, rapport of webpagina. 


Maximumkardinaliteit: (r) In een E-R-relatie, het maximale aantal entiteiten dat aan een ge- 
geven entiteit mag zijn gerelateerd. (2) In een relationele ontwerprelatie, het maximale 
aantal rijen dat aan een gegeven rij mag zijn gerelateerd. 

Me: In OOP, een speciale pointer naar de huidige objectinstantie. Me.Naam verwijst bijvoor- 
beeld naar het attribuut Naam van het huidige object. 

Mediastoring: Een storing die optreedt als het DBMS niet naar een schijf kan schrijven. Wordt 
meestal veroorzaakt door een schijfcrash of een andere schijfstoring. 

Meerlaagsstuurprogramma (multiple-tier driver) In ODBC, een uit twee delen bestaand 
stuurprogramma dat meestal voor een client-server-databasesysteem wordt gebruikt. Het 
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Java-bean: Een Java-klasse die zich op de juiste manier gedraagt. Beans hebben geen open- 
bare instantievariabelen — al hun persistente waarden worden benaderd via accessorme- 
thoden en ze hebben geen constructors, of precies één expliciet gedefinieerde constructor 
zonder argumenten. 


JavaScript: Een scripttaal van Netscape. De Microsoft-versie heet JScript en de standaardver- 
sie heet ECMAScript-262. Dit zijn vrij eenvoudig te leren geïnterpreteerde talen voor het 
verwerken van webserver- en webclient-toepassingen. Wordt soms geschreven als ‘Java 
Script’. 

Java-servlet: Zie: servlet. 


JDBC: Een standaardinterface aan de hand waarvan in Java geschreven applicatieprogram- 
ma's SQL-databases (of tabelstructuren zoals spreadsheets en teksttabellen) op een DB- 
MS-onafhankelijke manier kunnen benaderen en verwerken. De naam is geen afkorting 
van Java Database Connectivity. 


Join (samenvoeging): Een relationele algebrabewerking op twee relaties A en B, met als resul- 
taat een relatie C. Een rij van A wordt alleen aaneengeschakeld met een rij van B tot een 
rij in C als de rijen in A en B voldoen aan beperkingen voor hun waarden. Als Ar bijvoor- 
beeld een attribuut in A is en Br een attribuut in B, dan resulteert de join van A en B met 
als randvoorwaarde Ar < Br in een relatie C met de aaneenschakeling van rijen in A en B 
waarvoor geldt dat de waarde van Ar kleiner is dan de waarde van Br. Zie ook: equi-join 
en natural join. 


JScript: Een scripttaal van Microsoft. De Netscape-versie heet JavaScript en de standaardver- 
sie heet ECMAScript-262. Dit zijn vrij eenvoudig te leren geïnterpreteerde talen voor het 
verwerken van webserver- en webclient-toepassingen. 


JSP: Zie Java Server Page. 


Kandidaatsleutel: Een attribuut dat of een groep met attributen die een rij in een relatie op 
unieke wijze identificeert. Een van de kandidaatsleutels wordt gekozen als de primaire 
sleutel. 


Kardinaliteit: In een binaire relatie, het maximaal toegestane of minimaal benodigde aantal 
elementen aan elke kant van de relatie. De maximumkardinaliteit kan 1:1, 1:N, N:1 of N:M 
zijn. De minimumkardinaliteit kan optioneel-optioneel, optioneel-verplicht, verplicht-op- 
tioneel of verplicht-verplicht zijn. 


Keuzelijst (list box): In een GUl-omgeving, een element van de gebruikersinterface waarin 
een lijst met keuzemogelijkheden in een rechthoek wordt weergegeven. Het door de ge- 
bruiker met de cursor aangewezen item wordt in een andere kleur weergegeven dan de 
overige regels in de lijst. 

Keuzerondje (option button, radio button): In een GUI-omgeving, een element van de gebrui- 
kersinterface waarin de gebruiker een item uit een lijst kan kiezen. Als op het ene rondje 
wordt geklikt, wordt automatisch de selectie van elk ander eventueel op dat moment gese- 
lecteerde rondje ongedaan gemaakt. Werkt dus als de zenderkeuzeknop op een radio en 
is hetzelfde als een ‘radio button’, maar is wegens auteursrechten onder een andere naam 


geïntroduceerd. 
Key: Zie: sleutel. 
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Klassenattributen: In UML (Uniform Modeling Language) zijn dat attributen die betrekking 
hebben op de klasse van alle entiteiten van een bepaald type. 


Knooppunt (Node): (1) Een entiteit in een boomstructuur. (2) Een computer in een systeem 
voor gedistribueerde verwerking. 

Kolom: Een logische groep bytes in een rij van een relatie of een tabel. De betekenis van een 
kolom is gelijk voor elke rij in de relatie. 

Kolomobject: In Oracle, een objectstructuur die is opgeslagen in een tabelkolom. 

Krimpfase: In tweefaselocking, de fase waarin locks worden vrijgegeven en er geen locks 
meer worden geplaatst. 

Kubus: In OLAP, een presentatiestructuur met assen waarlangs gegevensdimensies wor- 
den geplaatst. Maateenheden van de gegevens staan in de cellen van de kubus. Zie ook: 
hyperkubus. 


LAMP: AMP dat onder Linux draait. Zie AMP. 
Leden (members): In OLAP, de waarden van een dimensie. 


List box: Zie: keuzelijst. 


Lock: Het proces van het toekennen van een databasebron aan een bepaalde transactie in een 
systeem voor gelijktijdige verwerking. De omvang van de gelockte bron staat bekend als 
de lockgranulariteit. Bij een exclusieve lock kan geen enkele andere transactie de bron le- 
zen of ernaar schrijven. Bij een shared lock mogen andere transacties de bron wel lezen, 


maar er niet naar schrijven. 


Lockgranulariteit: De omvang van een gelockt gegevenselement. De lock van een kolomwaar- 
de van een bepaalde rij is een lock met een fijne granulariteit en de lock van een complete 


tabel is een lock met een grove granulariteit. 

Log (logboek): Een bestand waarin alle databasewijzigingen worden vastgelegd. Het log bevat 
before images en after images. 

Lost update probleem: Zie: concurrent update probleem. 

M-score: Score (in RFM-analyse) die weergeeft hoeveel geld een klant per aankoop besteedt. 


Many-to-many (N:M) relatie: Zie: veel-op-veel-relatie. 

Maateenheid: In OLAP, de brongegevens voor de kubus — gegevens die in de cellen worden 
weergegeven. Dat kunnen oorspronkelijke gegevens zijn, of functies van deze gegevens, 
zoals SUM, AVG of andere berekeningen. 

Materialisatie: Een databaseview zoals die verschijnt in een formulier, rapport of webpagina. 

Maximumkardinaliteit: (r) In een E-R-relatie, het maximale aantal entiteiten dat aan een ge- 
geven entiteit mag zijn gerelateerd. (z) In een relationele ontwerprelatie, het maximale 
aantal rijen dat aan een gegeven rij mag zijn gerelateerd. 

Me: In OOP, een speciale pointer naar de huidige objectinstantie. Me.Naam verwijst bijvoor- 
beeld naar het attribuut Naam van het huidige object. 

Mediastoring: Een storing die optreedt als het DBMS niet naar een schijf kan schrijven. Wordt 
meestal veroorzaakt door een schijfcrash of een andere schijfstoring. 


Meerlaagsstuurprogramma (multiple-tier driver): In ODBC, een uit twee delen bestaand 
stuurprogramma dat meestal voor een client-server-databasesysteem wordt gebruikt. Het 
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ene deel van het stuurprogramma bevindt zich op de client en communiceert met de toe- 
passing en het andere deel staat op de server en communiceert met het DBMS. 


Meerwaardig attribuut: Het attribuut van een semantisch object met een maximumkardina- 
liteit groter dan één. 


Meerwaardige afhankelijkheid: Een situatie in een relatie met drie of meer attributen waarbij 
onafhankelijke attributen relaties lijken te hebben die ze in werkelijkheid niet hebben. Er 
is formeel sprake van meerwaardige afhankelijkheid in een relatie R(A, B, C) met de sleu- 
tel (A, B, C) als A verscheidene waarden van B (of van C of van beide) bepaalt en B en C 
onafhankelijk van elkaar zijn. Een voorbeeld is de relatie MEDEWERKER (MwNummer, 
MwFunctie, MwOndergeschikte), waarbij een medewerker verscheidene functies en ver- 
scheidene ondergeschikten kan hebben. MwFunctie en MwOndergeschikte hebben geen 
onderlinge relatie, hoewel ze wel samen in de relatie voorkomen. 


Members: Zie: leden. 


Menu: Een lijst met keuzemogelijkheden in een databasetoepassing (of een andere toepas- 
sing). De gebruiker selecteert de volgende actie of activiteit uit een lijst. Mogelijke acties 
zijn beperkt tot die in de lijst. Zie ook: opdracht. 


Metadata: Gegevens over de structuur van gegevens in een database, opgeslagen in de data- 
dictionary. Metadata worden gebruikt voor het beschrijven van tabellen, kolommen, rand- 
voorwaarden, indexen enzovoort. Zie ook: applicatiemetadata. 


Methode: Een programma dat gekoppeld is aan een objectgeoriënteerd programmeerobject 
(OOP-object). Een methode kan worden geërfd door OOP-objecten van een lager niveau. 


Minimumkardinaliteit: (rt) In een E-R-relatie, het minimale aantal entiteiten dat aan een ge- 
geven entiteit moet zijn gerelateerd. (2) In een relationele ontwerprelatie, het minimale 
aantal rijen dat aan een gegeven rij moet zijn gerelateerd. 


Modificatieanomalie: Zie: wijziginganomalie. 


MOLAP: Meerdimensionale OLAP met behulp van een speciale processor voor het onder- 
steunen van OLAP-verwerking. 


Multiple-tier driver: Zie: meerlaagsstuurprogramma. 

Muteerbaar object: In de standaard ODMG, een object waarvan de attributen kunnen worden 
gewijzigd. 

N:M: Een afkorting voor een veel-op-veelrelatie tussen entiteiten of rijen van een tabel. 


Natural join: Een join tussen een relatie A met attribuut Ar en een relatie B met attribuut Br 
waarbij Ar gelijk is aan Br. De resulterende relatie C bevat kolom Ar of kolom Br, maar 
niet beide. Zie ook: equi-join. 

Netwerk: (1) Een groep met elkaar verbonden computers, (2) een intranet of (3) het Internet. 


Netwerkgegevensmodel: Een gegevensmodel dat minimaal eenvoudige netwerkrelaties on- 
dersteunt. Het CODASYL DBTG-model is het bekendste netwerkgegevensmodel — dit 
model ondersteunt eenvoudige netwerkrelaties, maar geen complexe relaties. 


Niet-identificerende verbindingsrelaties: In IDEFIX, r:1 en r:N HEEFT-EEN-relaties waar 
geen 1D-afhankelijke entiteiten bij betrokken zijn. 


Niet-muteerbaar object: In de standaard ODMG, een object waarvan de attributen niet kun- 
nen worden gewijzigd. 


642 


BEGRIPPENLIJST 


Niet-objectattribuut: Een attribuut van een semantisch object dat geen object is. 

Niet-typegeldig document: Een XML-document dat niet voldoet aan zijn DTD of dat geen 
DTD heeft. Zie ook: typegeldig document en schemageldig document. 

Niet-specifieke relaties: In IDEF1X, een N:M-relatie. 


Niveau: In OLAP, een (mogelijk hiërarchische) deelverzameling van een dimensie. 


Node: Zie: knooppunt. 

Nonrepeatable reads: De situatie die optreedt als een transactie eerder gelezen gegevens in- 
leest en wijzigingen of verwijderingen ontdekt die het gevolg zijn van een doorgevoerde 
transactie. 


Normaalvorm: Een regel of verzameling regels over toegestane structuren van relatietabellen. 
Deze regels zijn van toepassing op attributen, functionele afhankelijkheden, meerwaardige 
afhankelijkheden, domeinen en randvoorwaarden. De belangrijkste normaalvormen zijn: 
INF, aNF, 3NF, Boyce-Codd-normaalvorm, 4NE, sNF en domein/sleutel-normaalvorm. 


Normalisatie: Het evalueren van een relatie om vast te stellen of deze in een normaalvorm 
staat en het zo nodig converteren ervan naar relaties in een gewenste normaalvorm. 
Nothing: In OOP, een objectverwijzing die wordt gebruikt om een objectpointer op null in te 

stellen of om te testen of een bepaalde objectpointer null is. 


Nullwaarde: Een attribuutwaarde die nooit is geleverd. Dergelijke waarden zijn dubbelzinnig 
en kunnen betekenen dat (a) de waarde onbekend is, (b) de waarde niet van toepassing is 


of (c) dat er bekend is dat de waarde leeg is. 


Object: (r) Een semantisch object. (2) Een structuur in een objectgeoriënteerd programma 
met een ingekapselde gegevensstructuur en gegevensmethoden. Zulke objecten worden 
zodanig in een hiërarchie gerangschikt dat objecten methoden van hun parents kunnen 
erven. (3) In beveiligingssystemen, een gegevenseenheid die door een wachtwoord of op 


een andere manier wordt beschermd. 
Objectattribuut: Een attribuut van een semantisch object dat een koppeling naar een object 
representeert. 
Objectconstructor: Bij objectgeoriënteerd programmeren, een functie die een object creëert. 
Objectdestructor: Bij objectgeoriënteerd programmeren, een functie die een object vernietigt. 
Objectdiagram: Een staande rechthoek die de structuur van een semantisch object voorstelt. 


Objectgeoriënteerd programmeren: Een stijl van computerprogrammeren waarbij program- 
ma's worden ontwikkeld als verzamelingen van objecten die gegevensleden en methoden 
hebben. Objecten communiceren met elkaar door elkaars methoden aan te roepen. 


Objectidentifier: Een attribuut dat wordt gebruikt om een objectinstantie te specificeren. Ob- 
jectidentifiers kunnen uniek zijn, in welk geval ze altijd dezelfde instantie identificeren, of 


niet uniek, wat betekent dat ze precies één objectinstantie identificeren. 


Objectinstantie: Een specifieke instantie van een bepaald semantisch object, bijvoorbeeld het 
semantische object VERKOPER waarvan Achternaam gelijk is aan Jager. 


Objectldasse: Bij objectgeoriënteerd programmeren, een verzameling objecten met dezelfde 
algemene structuur. 
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Objectklassenbibliotheek: Bij objectgeoriënteerd programmeren, een verzameling objectklas- 
sen, waarbij alle klassen in de verzameling meestal een soortgelijk doel hebben. 


Objectpersistentie: Bij objectgeoriënteerd programmeren, het kenmerk dat een object kan 
worden opgeslagen naar niet-vluchtig geheugen, zoals een schijf. Persistente objecten 
blijven bestaan nadat een programma afgesloten is. 


Object-relationeel DBMS: DBMS-product dat relationele en objectgeoriënteerde program- 
meergegevensstructuren ondersteunt, zoals Oracle. 


Objectview: Het deel van een semantisch object dat zichtbaar is voor een bepaalde toepassing. 
Een view bestaat uit de naam van het semantische object plus een lijst met attributen die 
zichtbaar zijn in deze view. 


ODBC: Zie: Open Database Connectivity-standaard. 


ODMG-93: Een rapport uitgegeven door de Object Data Management Group, een consortium 
van leveranciers van objectdatabases en andere belangstellenden. In het rapport worden 
de ideeën van een andere groep, de Object Management Group, toegepast op het pro- 
bleem van objectdatabases. Het eerste ODMG-rapport is opgesteld in 1993 en heeft als 
titel ODMG-93. 


OLAP: On-Line Analytical Processing. Een manier van dynamische gegevenspresentatie 


waarbij gegevens worden samengevat, geaggregeerd, gedeaggregeerd en weergegeven in 
de vorm van een tabel of kubus. 


OLE DB: De op COM-gebaseerde basis van gegevensbenadering in de Microsoft-omgeving. 


OLE DB-objecten ondersteunen de objectenstandaard OLE. ADO is gebaseerd op OLE 
DB. 


OLE-object: Object Linking en Embedding-object. COM-objecten die interfaces ondersteunen 
voor het inbedden in andere objecten. 


On-Line Analytical Processing: Zie: OLAP. 
One-to-one (r:1) relatie: Zie: een-op-een-relatie. 
One-to-many (r:N) relatie: Zie: een-op-veel-relatie. 
OOP: Zie: objectgeoriënteerd programmeren. 


Opdracht (command): Een statement dat door de gebruiker aan de databasetoepassing wordt 
verstrekt om een bepaalde bewerking uit te voeren. Zie ook: Menu. 


Open Database Connectivity-standaard (ODBC): Een standaardinterface via welke applicatie- 
programma’s SQL-databases (of tabelstructuren zoals spreadsheets en teksttabellen) op 
een DBMS-onafhankelijke wijze kunnen benaderen en verwerken. De stuurprogramma- 
manager van ODBC is ingebouwd in Windows. ODBC-stuurprogramma’s worden gele- 
verd door DBMS-leveranciers, door Microsoft en door andere softwareontwikkelbedrijven. 


Opgeslagen procedure (stored procedure): Een verzameling SQL-statements die zijn opge- 
slagen als een bestand dat door een enkele opdracht kan worden aangeroepen. DBMS- 
producten bieden meestal een taal voor het maken van opgeslagen procedures die de 
mogelijkheden van SQL uitbreidt met programmeertaalconstructies. Oracle levert PL/ 
SQL voor dit doeleinde en SQL Server voorziet in TRANSACT/SQL. Bij sommige produc- 
ten kunnen opgeslagen procedures in een standaardtaal zoals Java worden geschreven. 
Opgeslagen procedures worden in de database zelf opgeslagen. 
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Optimistische locking: Een lockstrategie die ervan uitgaat dat er geen conflict zal plaatsvin- 
den, een transactie verwerkt en vervolgens nagaat ofer toch een conflict is opgetreden. Als 
dat zo is, wordt de transactie afgebroken. Zie ook: pessimistische locking. 


Option button: Zie: keuzerondje. 

Orphan (wees): Elke rij (record) zonder parent in een verplichte een-op-veel-relatie. 

Outer join: Een join waarbij alle rijen van een tabel in de resulterende relatie voorkomen, of 
ze nu wel of niet voldoen aan de join-voorwaarde. In een left outer join verschijnen alle 
rijen uit de relatie aan de linkerkant en in een right outer join verschijnen alle rijen uit de 
relatie aan de rechterkant. 

Overerving (inheritance): Een kenmerk van objectgeoriënteerde systemen, waarbij subtype- 
objecten (children) attributen van hun supertypen (parents) overnemen. 

Overheadgegevens: Metadata gecreëerd door het DBMS om de verwerkingssnelheid te ver- 
groten. Bijvoorbeeld indexen en gekoppelde lijsten. 

Owner: Zie: eigenaar. 

Paarsgewijs attribuut: In een semantisch object komen objectattributen paarsgewijs voor. Als 
object A een objectattribuut van object B heeft, heeft object B automatisch een objectattri- 
buut van object A — de objectattributen komen dus paarsgewijs voor. 


Parent: Een rij of knooppunt aan de een-kant van een een-op-veel-relatie. 
Partitie: (1) Een deel van een gedistribueerde database. (2) Het deel van een netwerk dat is ge- 
scheiden van de rest van het netwerk tijdens een netwerkstoring. 


PDO: (PHP Data Objects) Een specificatie voor gegevenstoegang dat PHP-programmeurs in 
staat stelt dezelfde functies te gebruiken onafhankelijk van het gebruikte DBMS. 


Persistent object: Een OOP-object dat naar een persistente opslagplaats is geschreven. 


Pessimistische locking: Een lockstrategie die conflicten voorkomt door locks te plaatsen voor- 
dat databaselees- en schrijfverzoeken worden verwerkt. Zie ook: optimistische locking en 


deadlock. 
Phantom reads: De situatie die optreedt als een transactie eerder gelezen gegevens inleest en 
daarbij nieuwe rijen aantreft die door een doorgevoerde transactie zijn ingevoegd. 


PHP: Een scripttaal om dynamische webpagina's te maken. Bevat objectgeoriënteerde com- 
ponenten en PHP Data Objects (Zie PDO). 


PL/SQL: Programming Language for SQL. Een door Oracle geleverde taal die SQL uitbreidt 
met programmeertaalstructuren zoals while-lussen, if:then-else-blokken en andere con- 


structies. PL/SQL wordt gebruikt voor het maken van opgeslagen procedures en triggers. 


Plat bestand: Zie: Flat file. 

Pointer: Een adres naar een instantie van een gegevenselement in een structuur. 

Polymorfie: In OOP de situatie waarin een enkele naam kan worden gebruikt voor het aan- 
roepen van verschillende functies. Polymorfie waarin de functies worden onderscheiden 
door verschillende volgordes van parameters, wordt ook wel parametrische polymorfie ge- 
noemd. De namen worden tijdens het compileren door de compiler ingevuld. Polymorfie 
waarbij de functies worden onderscheiden door objectovererving, wordt ook wel overer- 
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vingspolymorfie genoemd. De namen worden hier tijdens runtime ingevuld door vast te 
stellen welk objecttype wordt aangeroepen. 


Primaire sleutel: De kandidaatsleutel die is gekozen als de sleutel van een relatie. 


Processing interface-subsysteem: Het deel van het DBMS dat opdrachten voor bewerkingen 
op de database uitvoert. Het accepteert invoer van interactieve queryprogramma'’s en van 
applicatieprogramma’s geschreven in standaardtalen of DBMS-specifieke talen. 


Programma/gegevensonafhankelijkheid: De situatie waarin de structuur van de gegevens 
niet in applicatieprogramma's wordt gedefinieerd. De structuur wordt in plaats daarvan 
in de database gedefinieerd en de applicatieprogramma’s verkrijgen de structuur daarna 
van het DBMS. Op deze manier kunnen wijzigingen in de gegevensstructuren worden 
aangebracht zonder dat de applicatieprogramma'’s moeten worden aangepast. 


Property: Hetzelfde als attribuut. 
Proponent: Zie: gegevensverantwoordelijke. 
Prototype: Een demonstratieversie van een (deel van een) toepassing die snel is gemaakt. 


QBE: Query-by-example. Een stijl van queryinterface, ontwikkeld door IBM, die nu ook door 
andere leveranciers wordt gebruikt, die gebruikers in staat stelt query's uit te drukken 
door voorbeelden te leveren van de resultaten die ze zoeken. 


Query /updatetaal: Een taal waarmee eindgebruikers gegevens uit de database kunnen opvra- 
gen en bewerken. 


Queryinterface: Een interface in Microsoft-COM die kan worden gebruikt om te bepa- 


len welke objecten, methoden en eigenschappen door een ActiveX-programma worden 
ondersteund. 


R-score: De score (in RFM-analyse) die weergeeft hoe recent een klant een aankoop deed. 


Randvoorwaarde (constraint): Een regel die aangeeft welke attribuutwaarden tot een geldig 
resultaat kunnen leiden. Een randvoorwaarde omvat volgens de definitie van de domein/ 
sleutel-normaalvorm geen dynamische, aan de tijd gerelateerde regels zoals ‘Verkoper Sa- 
laris kan nooit afnemen’ of ‘Salaris_nu moet groter zijn dan Salaris_vorig_kwartaal’. 


Rapportagesysteem: Een business intelligence systeem dat gegevens verwerkt door filteren, 
sorteren en het maken van eenvoudige berekeningen. OLAP is een voorbeeld van zo'n 
systeem. Tegenhanger is dataminingsysteem. 


RDS: Zie: Remote Data Services. 


Read committed: Een transactie-isolatieniveau dat dirty reads verbiedt, maar wel nonrepeata- 
ble reads en phantom reads toestaat. 


Read uncommitted: Een transactie-isolatieniveau dat dirty reads, nonrepeatable reads en 
phantom reads toestaat. 


Record: (1) Een groep velden die betrekking hebben op dezelfde entiteit — wordt gebruikt 
in bestandsverwerkingssystemen. (2) In een relationeel model, een synoniem voor rij of 
tuple. 


Recordset: Een ADO-object dat een relatie voorstelt — gecreëerd als het resultaat van het uit- 
voeren van een SQL-statement of een opgeslagen procedure. 


646 


BEGRIPPENLIJST 


Recursieve relatie: Een relatie tussen entiteiten, objecten of rijen van hetzelfde type. Als 
KLANTen bijvoorbeeld verwijzen naar andere KLANTen, dan is de relatie verwijst naar een 


recursieve relatie. 

ReDo-bestanden: In Oracle, back-ups van rollback-segmenten, die worden gebruikt voor 
back-up en recovery. Er bestaan online en offline ReDo-bestanden. 

Referentiële integriteitsacties: Regels die opgeven welke activiteiten er moeten worden uitge- 
voerd als er invoeg-, bijwerk- of verwijderacties optreden in de parent- of de childentiteiten 
in een relatie. Mogelijke acties zijn none (geen actie), cascading (trapsgewijs uitvoeren), 
set default (standaardwaarde instellen), set null (de waarde null instellen) en restrict (de 
waarde beperken). 

Referentiële integriteitsvoorwaarde: Een relatierandvoorwaarde voor waarden van externe 
sleutels. Een referentiële integriteitsvoorwaarde geeft aan dat de waarden van een externe 
sleutel een correcte deelverzameling moeten zijn van de waarden van de primaire sleutel 
waar de externe sleutel naar verwijst. 

Relatie: (1) Tabel — een tweedimensionale array dat enkelwaardige gegevens bevat, zonder 
dubbele rijen. De betekenis van de kolommen is hetzelfde voor elke rij. De volgorde van 
de rijen en kolommen is onbelangrijk. (2) Een koppeling tussen twee entiteiten, objecten 
of rijen van relaties. 

Relatiekardinaliteitsrandvoorwaarde: Een randvoorwaarde gesteld aan het aantal rijen dat kan 
deelnemen aan een relatie. De minimale kardinaliteitsrandvoorwaarden bepalen het aan- 
tal rijen dat moet deelnemen en de maximale kardinaliteitsrandvoorwaarden geven aan 
hoeveel rijen er maximaal mogen deelnemen. 

Relationeel gegevensmodel: Een gegevensmodel waarbij gegevens worden opgeslagen in re- 
laties en waarbij relaties tussen rijen worden voorgesteld door gegevenswaarden. 

Relationeel schema: Een verzameling relaties met referentiële integriteitsvoorwaarden en an- 
dere aan de relaties opgelegde randvoorwaarden. 

Relationele database: Een database die uit relaties is opgebouwd. In de praktijk en re- 
lationele databases vaak relaties met dubbele rijen. De meeste DBMS-producten Be 
een mogelijkheid voor het verwijderen van gedupliceerde rijen. Dergelijke rijen worden 
standaard niet verwijderd, omdat dat veel tijd en moeite kan kosten. 

Remote Data Services (RDS): Een verzameling ActiveX-besturingselementen en functies 
waarmee gegevens kunnen worden gebufferd op een clientmachine en vervolgens kun- 
nen worden opgemaakt, gesorteerd en gefilterd zonder hulp van de webserver. 

Repeatable read: Een transactie-isolatieniveau dat dirty reads en nonrepeatable reads verbiedt. 
Phantom reads kunnen wel voorkomen. 

Replicatie: In Oracle en SQL Server, een term die verwijst naar databases die op meer dan één 
computer worden opgeslagen. 

Replicatietransparantie: In een gedistribueerd databasesysteem de situatie waarin applicatie- 
programma’s niet weten en ook niet hoeven te weten of gegevens gerepliceerd zijn. Het 
DDBMS zorgt er automatisch voor dat alle kopieën op consistente wijze worden bijge- 
werkt, dus zonder tussenkomst van het applicatieprogramma. 

Repository: Een verzameling metadata over databasestructuur, toepassingen, webpagina's, 
gebruikers en andere applicatiecomponenten. Actieve repository's worden automatisch 
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bijgehouden door tools in de applicatieontwikkelomgeving. Passieve repository’s moeten 
met de hand worden bijgewerkt. 


Resource locking: Zie: lock. 


Resource-sharingarchitectuur: De structuur van een Local Area Network waarin één mi- 
crocomputer de bestandsverwerking uitvoert voor andere microcomputers. In een 
databasetoepassing bevat elke gebruikerscomputer een kopie van het DBMS dat in- en uit- 
voerverzoeken naar de file-server doorstuurt. De file-server verzorgt alleen de bestands-1/O 
— alle databaseactiviteiten worden uitgevoerd door het DBMS op de gebruikerscomputer. 


Reverse engineered gegevensmodel: Het gegevensmodel dat het resultaat is van reverse engi- 
neering. Het is geen conceptueel model, want het omvat fysieke structuren zoals doorsne- 
detabellen. Het is echter meer conceptueel dan een databaseschema. 


Reverse engineering: Het proces van het lezen van de structuur van een bestaande database 
en het maken van een reverse engineered gegevensmodel op basis van dat schema. 


RFM-analyse: Rapportagesysteem dat klanten indeelt naar hun koopgedrag: hoe recentelijk 
(R) heeft een klant besteld, hoe vaak (frequently — F), en hoeveel geld (money — M) heeft 
de klant per bestelling besteedt. 


Rij: Een groep kolommen in een tabel. Alle kolommen in een rij hebben betrekking op de- 
zelfde entiteit. Een rij is hetzelfde als een tuple of een record. 


Rij-identifier: In SQL3, een unieke, door het systeem geleverde identifier — een surrogaatsleu- 


tel. De rij-identifier kan zichtbaar worden gemaakt door WITH IDENTITY aan de tabel- 
definitie toe te voegen. 


Rijobject: In Oracle, een tabel die objecten als zijn rijen bevat. 


Rijset: In OLE DB, een abstractie van gegevensverzamelingen zoals recordsets, e-mailadres- 
sen en niet-relationele en andere gegevens. 


ROLAP: Relationele OLAP, waarbij gebruik wordt gemaakt van een relationeel DBMS voor 
het ondersteunen van OLAP-verwerking. 


Rollback: Een herstelprocedure voor een database, waarbij before images worden toegepast 


op de database om terug te keren naar een eerder checkpoint of een ander punt waarop de 
database logisch consistent was. 


Rollbacksegment: In Oracle, een buffer die wordt gebruikt om before images op te slaan 
voor concurrencybeheer en transactielogging. Rollbacksegmenten kunnen worden gear- 
chiveerd en later worden gebruikt voor recovery. 


Rollforward: Een herstelprocedure voor een database, waarbij after images worden toegepast 
op een opgeslagen kopie van de database om een checkpoint te bereiken, of een ander 
punt waarop de database logisch consistent is. 

Root: Zie: wortel. 


Samengesteld object (composite object): Een object met ten minste één meerwaardig(e) 
attribuut(groep). Wordt een samengesteld object genoemd, omdat de sleutel van de re- 
Jatie die dit attribuut of deze attribuutgroep vertegenwoordigt altijd een samengestelde 
sleutel is. 

Samengestelde groep (composite group): Een groep attributen in een semantisch object dat 
meerwaardig is en geen andere objectattributen bevat. 
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Samengestelde sleutel (composite key): Een sleutel met meer dan één attribuut. 
Samenvoeging: Zie: join. 


SAX: Simple API (applicatieprogramma-interface) for XML. Een op gebeurtenissen gebaseer- 
de parser die een programma waarschuwt als hij tijdens het parsen elementen van een 
XML-document tegenkomt. 


Schema: Een volledige logische view van de database. 

Schemageldig document: Een XML-document dat voldoet aan zijn XML Schemadefinitie. 

Schuifbare cursor: Een cursortype dat vooruit en achteruit bewegen door een recordset mo- 
gelijk maakt. In dit boek zijn drie schuifbare cursortypen behandeld: snapshot of statisch, 
keyset en dynamisch. 

SCN: Zie: System Change Number. 

Selectievakje (check box): In een GUI-omgeving, een element van de gebruikersinterface 
waarin een gebruiker een of meer items uit een lijst kan kiezen door op ze te klikken. 

Semantisch objectdiagram: Hetzelfde als een objectdiagram. 


Semantisch objectmodel: De constructies en afspraken die worden gebruikt om een model 
van de gebruikersgegevens op te stellen. De grootheden in de gebruikersomgeving wor. 
den voorgesteld door semantische objecten (soms kortweg objecten genoemd). Relaties 
worden in de objecten gemodelleerd en de resultaten worden meestal in objectdiagram- 


men gedocumenteerd. 

Semantische objectview: Het deel van een semantisch object dat zichtbaar is in een formulier 
of een rapport. 

Serializable (serialiseerbaar): Een transactie-isolatieniveau dat dirty reads, nonrepeatable 
reads en phantom reads niet toestaat. 

Serviceprovider: Een OLE DB-gegevensleverancier die gegevens transformeert. Een service- 
provider is zowel een gegevensconsument als een gegevensleverancier. 

Servlet: Een gecompileerd, machineonafhankelijk Java-bytecodeprogramma dat wordt uitge- 
voerd door een Java virtuele machine op een webserver. 

SGML: Zie: Standard Generalized Markup Language. 

Shared lock (gedeelde lock): Een lock op een gegevensbron waarbij slechts één transactie de 
gegevens mag wijzigen, maar die het veel transacties toestaat de gegevens tegelijkertijd 
te lezen. 

Sibling: Een record of knooppunt met dezelfde parent als een andere record of een ander 
knooppunt. 

Simple Object Access Protocol: Een standaard die wordt gebruikt voor externe procedureaan- 
roepen. Gebruikt XML voor het definiëren van de gegevens en http voor het transport. Zie 
ook: SOAP. 


Single-tier driver: Zie: eenlaagsstuurprogramma. 
Sleutel (key): () Een groep van een of meer attributen die een rij in een relatie op unieke 
wijze identificeren. Omdat in relaties geen dubbele rijen mogen voorkomen, moet elke 
relatie over minstens één sleutel beschikken, die de samenstelling is van alle attributen in 
de relatie. Wordt soms ook wel een logische sleutel genoemd. (2) In bepaalde relationele 
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DBMS-producten, een index op een kolom om gegevens sneller te benaderen en te sorte- 
ren. Wordt soms ook wel een fysieke sleutel genoemd. 


Slice: In OLAP, een dimensie of maateenheid die voor een bepaalde weergave constant wordt 
gehouden. 


Sneeuwvlokschema: Een tabelstructuur in een OLAP-database waarbij de dimensietabellen 
een aantal niveaus verwijderd kunnen zijn van de tabel met de meetwaarden. Dergelijke 
dimensietabellen worden meestal genormaliseerd. Zie ook: sterschema. 


SOAP: Origineel: Simple Object Access Protocol. Dit is tegenwoordig een protocol voor het 
verzenden van procedureaanroepen die van het Simple Object Access Protocol verschilt, 
omdat er ook andere protocollen naast http kunnen worden gebruikt. 


SQL: Structured Query Language. Een taal voor het definiëren van de structuur en het ver- 
werken van een relationele database. Kan op zichzelf worden gebruikt, of kan worden in- 
gebed in applicatieprogramma’s. De meest voorkomende versie is SQL-92, een versie die 
in 1992 door het ANSI (American National Standards Institute) is geaccepteerd als een 
Amerikaanse nationale standaard. SQL is origineel ontwikkeld door IBM. 


SQL3: SQL3 is een uitbreiding op de databasestandaard SQL-g2 en biedt ondersteuning voor 
objectgeoriënteerd databasebeheer. Ontwikkeld door de standaardisatiecommissies ANSI 
X3H2 en ISO/IEC JTC1/SC21/WG3. 


SQL-view: Een relatie die wordt geconstrueerd uit één SQL SELECT-statement. SQL-views 
hebben maximaal één meerwaardig pad. De term view betekent in de meeste DBMS-pro- 
ducten, inclusief Access, Oracle en SQL Server, SQL-view. 


Standaardnaamruimte (default namespace): In een XML Schemadocument, de naamruimte 
die wordt gebruikt voor alle niet-gelabelde elementen. 


Standard Generalized Markup Language (SGML): Een standaardmethode voor het marke- 
ren van de opmaak, structuur en inhoud van documenten. HTML is een toepassing van 
SGML. XML is een subset van SGML. 


Statementniveau, consistentie op: Alle rijen waarop een bepaald SQL-statement betrekking 
heeft, worden beschermd tegen wijzigingen door andere gebruikers gedurende het uit- 
voeren van het statement. Zie ook: transactieniveau, consistentie op. 


Sterke entiteit: In het E-R-model, een entiteit waarvan het bestaan in de database niet afhan- 


kelijk is van de aanwezigheid van een andere entiteit. Zie ook: ID-afhankelijke entiteit en 
zwakke entiteit. 


Sterschema: Een tabelstructuur in een OLAP-database waarbij elke dimensietabel grenst aan 
de tabel met de meetwaarden. In een sterschema zijn de dimensietabellen vaak niet ge- 
normaliseerd. Zie ook: sneeuwvlokscherma. 


Stored procedure: Zie: opgeslagen procedure. 


Storingstransparantie: In een gedistribueerd databasesysteem, de toestand waarin applicatie- 
programma's storingsongevoelig zijn. 


Stuurprogramma (driver): In ODBC, een programma dat fungeert als een interface tussen de 
ODBC-stuurprogramma-manager en een bepaald DBMS-product. Draait op de clientma- 
chines in een client-serverarchitectuur. 
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Stuurprogramma-manager (driver manager): In ODBC, een programma dat fungeert als 
een interface tussen een applicatieprogramma en een ODBC-stuurprogramma. Bepaalt 
het vereiste stuurprogramma, laadt dit in het geheugen en coördineert de activiteit tus- 
sen de toepassing en het stuurprogramma. Wordt op Windows-systemen geleverd door 


Microsoft. 

Subtabel: In SQL3, een tabel die een subtype is van een andere tabel, de zogeheten supertabel. 

Subtype: In generalisatiehiërarchieën een entiteit die of een object dat een subcategorie 
is van een type van een hoger niveau. Bijvoorbeeld: INGENIEUR is een subtype van 
MEDEWERKER. 

Supertabel: In SQL3, een tabel met een of meer subtabellen. 

Supertype: In generalisatiehiërarchieën, een entiteit die of een object dat logisch gezien een 
aantal subtypen bevat. Bijvoorbeeld: MEDEWERKER is een supertype van INGENIEUR, 
BOEKHOUDER en MANAGER. 

Surrogaatsleutel: Een unieke, door het systeem geleverde identifier die als de primaire sleutel 
van een relatie wordt gebruikt. De waarden van een surrogaatsleutel hebben geen beteke- 
nis voor de gebruikers en zijn meestal verborgen in formulieren en rapporten. 

Swizzling: In OOP, het omzetten van een permanente objectidentifier in een adres in het ge- 
heugen, of omgekeerd. 

Systeemgegevensbron: Een ODBC-gegevensbron die lokaal is voor één computer en kan wor- 
den benaderd door het besturingssysteem van die computer en bepaalde gebruikers van 
dat besturingssysteem. 

System Change Number (SCN): In Oracle, een voor de hele database geldende waarde die 
wordt gebruikt om wijzigingen in de databasegegevens te ordenen. Het SCN wordt met 
één verhoogd als wijzigingen in de database worden doorgevoerd. 

Tabulaire gegevensleverancier: Een OLE DB-gegevensleverancier die gegevens aanbiedt in de 
vorm van rijsets. 

Tak (branch): Een subelement van een boomstructuur dat kan bestaan uit een of meer 


knooppunten. 
Target namespace (doelnaamruimte): In een XML Schemadocument, de naamruimte die 


door het schema gemaakt zal worden. 


Three-tier architecture: Zie: drielaagsarchitectuur. 

Toepassing: Een bedrijfscomputersysteem dat een deel van een database verwerkt om te vol. 
doen aan de informatiebehoeften van een gebruiker. Bestaat uit menu's, formulieren, rap- 
porten, query's, webpagina's en applicatieprogramma's. 

Top-down-databaseontwerp: Het ontwerpen van een database waarbij vanuit het alge- 
mene naar het specifieke wordt gewerkt. De resulterende database kan alle behoeften 
binnen een organisatie dekken, maar het gevaar bestaat dat zij nooit af komt. Zie ook: 


bottom-up-databaseontwerp. 


TRANSACIJSQL: Een taal van Microsoft die onderdeel is van SQL Server. Het is een uit- 
breiding op SQL met programmeertaalstructuren zoals while-lussen, if-then-else-blokken 


en andere constructies. TRANSACIJSQL wordt gebruikt voor het maken van opgeslagen 
procedures en triggers. Wordt soms ook wel T/SQL genoemd. 
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Transactie: (1) Een atomaire transactie. (2) Zakelijke overeenkomst. 


Transactiegrens: De groep databaseopdrachten die als één geheel moet worden doorgevoerd 
of worden geannuleerd. 


Transactie-isolatieniveau: De mate waarin een databasetransactie is beschermd tegen bewer- 
kingen van andere transacties. De SQL-standaard uit 1992 heeft vier isolatieniveaus ge- 
specificeerd: Read Uncommitted, Read Committed, Repeatable Reads en Serializable. 


Transactieknooppunt: In een gedistribueerd databasesysteem, een computer die een gedistri- 
bueerde transactiemanager verwerkt. 


Transactieniveau, consistentie op: Alle rijen waarop een van de SQL-statements in een trans- 
actie betrekking heeft, worden beschermd tegen wijzigingen gedurende de gehele trans- 
actie. Deze mate van consistentie is lastig op te leggen en resulteert meestal in een lagere 
verwerkingssnelheid. Het kan ook betekenen dat een transactie haar eigen wijzigingen 
niet kan zien. Zie ook: statementniveau, consistentie op. 


Transiënt object: In OOP, een object dat niet is geschreven voor permanente opslag. Het ob- 
ject gaat verloren als het programma wordt beëindigd. 


Transitieve afhankelijkheid: In een relatie met minstens drie attributen, bijvoorbeeld R(A, B, 
C), de situatie waarin A B bepaalt en B C bepaalt, maar B niet A bepaalt. 


Trapsgewijze updates (cascading updates): Een referentiële integriteitsactie die bepaalt dat de 
overeenkomstige externe sleutels in childrijen ook moeten worden bijgewerkt als de sleu- 
tel van een parentrij wordt bijgewerkt. 


Trapsgewijze verwijdering (cascading deletion): Een referentiële integriteitsactie die bepaalt 
dat alle gerelateerde childrijen ook moeten worden verwijderd als er een parentrij wordt 
verwijderd. 


Tree: Zie: boomstructuur. 


Trigger: Een special type opgeslagen procedure dat wordt aangeroepen door het DBMS als 
aan een vooraf opgegeven voorwaarde wordt voldaan. BEFORE-triggers worden uitge- 
voerd vóór een opgegeven databasebewerking, AFTER-triggers worden gestart ná een op- 
gegeven databasebewerking en INSTEAD OF-triggers worden uitgevoerd in plaats van 
een opgegeven databasebewerking. INSTEAD OF-triggers worden normaliter gebruikt 
voor het bijwerken van gegevens in SQL-views. 


T-SQL: Zie: Transact-SQL. 
Tuple: Synoniem voor rij. 


Tweede normaalvorm: Een relatie in eerste normaalvorm waarbij alle niet-sleutelattributen 
van de volledige sleutel afhankelijk zijn. 


Tweefasedoorvoeralgoritme (two-phase commitment): In een gedistribueerd databasesys- 
teem, een algoritme waarbij knooppunten ‘stemmen’ over de vraag of ze een transactie 
kunnen doorvoeren. Als alle knooppunten ‘Ja’ stemmen, wordt de transactie doorgevoerd. 
Als een van de knooppunten ‘Nee’ stemt, wordt de transactie afgebroken. Een tweefase- 
doorvoeralgortime is nodig om inconsistente verwerking in gedistribueerde databases te 
voorkomen. 


Tweefaselocking: Een procedure waarbij locks in twee fasen worden geplaatst en vrijgege- 
ven. Tijdens de groeifase worden de locks geplaatst en in de krimpfase worden ze weer 
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Vrijgegeven. Zodra er een lock is vrijgegeven, wordt die transactie aan geen enkele andere 
lock meer verleend. Een dergelijke procedure zorgt voor consistentie in databasewijzigin- 
gen in een omgeving waar gelijktijdige verwerking plaatsvindt. 

Typedomein: In IDEF1X, een domein dat is gedefinieerd als een subset van een basisdomein 
of een ander typedomein. 

Typegeldig document: Een XML-document dat in overeenstemming is met zijn DTD. Zie 
ook: niet-typegeldig document. 

UML: Unified Modeling Language. Een verzameling structuren en technieken voor het mo- 


delleren en ontwerpen van objectgeoriënteerde programma's en toepassingen. UML is 
zowel een methodiek als een verzameling ontwikkeltools. UML omvat het E-R-model voor 


gegevensmodellering. 

Unified Modeling Language: Zie: UML. 

Updatable view: Een SQL-view die kan worden bijgewerkt. De regels die bepalen of een view 
al dan niet kan worden bijgewerkt zijn erg ingewikkeld. Zie figuur 7.13. Niet-bijwerkbare 
views kunnen bijwerkbaar worden gemaakt door INSTEAD OF-triggers te schrijven. 

User view: In het model met drie schema's, het deel van de database dat door een gebruiker 
of een groep gebruikers wordt bekeken. Synoniem voor externe view. 

VBScript: Een vrij eenvoudig te leren geïnterpreteerde taal voor het verwerken van webserver- 
en webclient-toepassingen — een subtaal van Microsoft Visual Basic. 

Veel-op-veel-relatie: Een relatie waarbij een parent (of een rij in een parenttabel) gerelateerd is 
aan veel childinstanties (of rijen in een childtabel). Tegelijkertijd kan een childinstantie (of 
rij in de childtabel) gerelateerd zijn aan veel parentinstanties (of rijen in de parenttabel). 

Veld: (rt) Een logische groep bytes in een record bij bestandsverwerking. (2) In de context van 
een relationeel model een synoniem voor attribuut. 

Verbindingsrelatie: In IDEFrX, een r:1 of 1:N HEEFT-EEN-relatie. 

Verticale beveiliging: Toegang beperken tot bepaalde kolommen van een tabel of join. 

Verticale partitie: Een deelverzameling van de kolommen van een tabel. Bijvoorbeeld de eer- 
ste vijf kolommen in een tabel met tien kolommen. 

Verwerkingsrechten en -verantwoordelijkheden: Beleid van een organisatie waarin is vast- 
gelegd wie welke handelingen mag uitvoeren op bepaalde gegevenselementen of andere 
gegevensverzamelingen. 

Verwijderanomalie: Treedt op in een relatie als er gegevens over twee of meer onderwerpen 
verloren gaan als er een enkele rij uit een tabel wordt verwijderd. 

Verzameling (collection): Een object dat een groep andere objecten bevat. Voorbeelden zijn de 
Names-, Errors- en Parameters-verzamelingen in ADO. 

Vierde normaalvorm: Een relatie in Boyce-Codd-normaalvorm waarin elke meerwaardige af. 
hankelijkheid een functionele afhankelijkheid is. 

View: Een gestructureerde lijst met gegevenselementen van entiteiten of semantische objec- 
ten die gedefinieerd zijn in het gegevensmodel. 

Volledige categoriecluster: Een categoriecluster waarin alle mogelijke categorie-entiteiten zijn 
gedefinieerd. De algemene entiteit moet een van de categorie-entiteiten zijn. 
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WAMP: AMP dat onder Windows draait. Zie: AMP. 
Wees: Zie: orphan. 


Wijziginganomalie: Een situatie waarbij door het opslaan van één rij in een tabel feiten over 
twee of meer onderwerpen worden vastgelegd of waarbij door het verwijderen van één rij 
uit een tabel feiten over twee of meer onderwerpen worden geëlimineerd. 


Wortel (root): De bovenste record, rij of het bovenste knooppunt in een boomstructuur. Een 
wortel heeft geen parent. 


XML: eXtensible Markup Language. Een standaardmarkeertaal die zorgt voor een duidelij- 
ke scheiding tussen structuur, inhoud en materialisatie. Kan willekeurige hiërarchieën 
representeren en daarom worden gebruikt voor het overdragen van elke willekeurige 
databaseview. 


XML Namespaces: Een standaard waarmee namen aan gedefinieerde verzamelingen kun- 
nen worden toegekend. X:Naam wordt geïnterpreteerd als het element Naam zoals het is 
gedefinieerd in de naamruimte X. Y:Naam wordt geïnterpreteerd als het element Naam 


zoals het is gedefinieerd in de naamruimte Y. Handig om dubbelzinnigheid van bepaalde 
termen te voorkomen. 


XML Schema: Een taal die in overeenstemming is met XML, waarmee de structuur van 
een XML-document kan worden vastgelegd. Is een uitbreiding op en vervanging van 


DTD's. De standaarden worden nog steeds verder ontwikkeld — erg belangrijk voor 
databaseverwerking. 


XPath: Een subtaal binnen XSLT waarmee te transformeren onderdelen van een XML-docu- 


ment worden geïdentificeerd. Kan ook worden gebruikt voor berekeningen en stringma- 
nipulatie. Vermengd met XSLT. 


XPointer: Een standaard voor het aan elkaar koppelen van documenten. XPath bevat veel ele- 
menten van XPointer. 


XQuery: Een standaard waarmee databasequery’s als XML-documenten kunnen worden uit- 
gedrukt. De structuur van de query gebruikt XPath-voorzieningen en het resultaat van de 


query wordt afgebeeld in een XML-indeling. Is nog in ontwikkeling en zal in de toekomst 
waarschijnlijk belangrijk worden. 


XSL: XSLT Stylesheet. Het document dat zorgt voor de (overeenkomst, actie}-paren en an- 


dere gegevens voor XSLT die kunnen worden gebruikt tijdens het transformeren van een 
XML-document. 


XSLT: Extensible Style Language: Transformations. Een programma (of proces) dat XSLT 
Stylesheets toepast op een XML-document voor het produceren van een getransformeerd 
XML-document. 


Zwakke entiteit: In het E-R-model, een entiteit waarvan het logische bestaan in de database 
afhangt van het bestaan van een andere entiteit. Zie ook: 1D-afhankelijke entiteit, sterke 
entiteit en identificerende verbindingsrelatie. 
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